What type of test environment to use?

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.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

1 thought on “What type of test environment to use?”

  1. That’s interesting – I hadn’t really thought about the advantages of testing in a local environment before. It would also mean faster responses from a web application, so you could execute a large number of test cases in Watir, WebDriver, etc, then make a change or tweak and run them again without having to wait a long time.

    But as you eloquently mention in your second paragraph, local testing is no substitute for testing in a hosted, integrated environment that’s as close as possible to production.


Comments are closed.