This post is part of the Pride & Paradev series.
What type of test environment should you use to test user stories?
Use a local test environment
If you’re working on automated tests as a tester then chances are you’ve got your application’s code-base checked out and running locally.
It’s easy to use this locally running code base to conduct your story testing. The benefits are that it’ll be very up to date, and as a programmer commits a change, you can grab the changes and you’ll be working on a fresh copy.
As part of your testing, you can change what you wish, like application settings and database config to see what happens as you test without having to worry about impacting anyone else using the test environment.
You can even fix some bugs as you find them (if you choose to).
Use an integrated test environment
You should always test your user stories in an integrated test environment.
One reason is that when you’re testing; you’re not only testing your application, but that your application can be deployed and work in a dedicated environment. This means you’ll find issues that don’t appear locally – like forgetting to include a file to be deployed, which will not show when testing locally.
You also test that you can access your application over the network using an external IP address, rather than using localhost, and iron out any connectivity issues.
You’re also testing how your application performs under more realistic hardware than on just your development machine.
It’s relatively easy to set up an automated continuous delivery pipeline to deploy automatically to a test environment so you can test stories as they are completed by the programmers.