Software Testing Environments Best Practices

When you learn to program, everything happens on the same computer, but when you start working for a (structured) organization, you realize the risks of changing and testing code directly where your users or customers are working. Thus you will have separated environments for developing, integrating or releasing your system. In this article, Richard Ellison provides some best practices for software testers on how to manage software testing environments.

Author: Richard Ellison, The QA People, http://theqapeople.com/

Code appears in different areas for different reasons and ultimately for different usage. Each environment has a specific purpose and as a tester understanding these environments and can be key to implementation of a successful software testing and quality assurance strategy. I will run through a very high level overview of the most common software testing environments. Do not get concerned if the naming does not match what your organization uses. As long as you have the key understanding of the environments you should be able to get the information you need.

Before we review a few best practices around the environment I wanted to offer a quick overview with some initial details on each environment.

DEV (Development Environment) – This is the environment the developers will write the code in. Before I say anything about DEV I have to say this to software testers: never test in dev. This is the golden rule. It is right next to don’t let the developers run the test for QA. I did not add this as best practice since it is simply the only approach that can be taken. The reason you cannot test in DEV is developers are always checking in code and working on defects. They will do their unit tests, but as a software tester you need a non-moving platform to verify if things are working as expecting. On top of that you need to test in a production like environment and dev will not offer the data or the set up to perform this normally. In dev you also can have complexities with multiple projects being worked on in one environment. A lot of times this is managed through branching and merging the code. As developers are always checking in code and working on defects, it is expected that the environment will be stable but not as stable as any of the other environments.

QA (Testing/ Quality Assurance Environment) – Once the developer performs the unit test cases, the code will be moved into QA to start testing. Often you will have a few environments for testing. For example you will have one set up for system testing and another that is used for performance testing and yet another that is used for user acceptance testing (UAT). This is caused by the unique needs for each type of testing. The reason you cannot test in DEV is developers are always checking in code and working on defects. You need a non-moving platform to verify if things are working as expecting.

SANDBOX – This is what it sounds like. It is a development playground to try new things out. It is of no consequence to you and if you are using the sandbox as a tester in any way, it is important to escalate within the QA department as soon as possible.

STAGING – As you move the code from one environment to another, you will use the staging environment. It is not likely that you will ever need to use the staging environment for software testing, unless you are performing pre-production implementation testing in this environment.

PROD (Production) – This is the external application where it is available to the client. Production should not be updated until the scheduled go live. If it will be updated prior to go live escalate. No testing will take place in production prior to go live. Production does not have to be available to clients to be impacting to the rest of the system. If the code is live the integration impacts can be seen. So do not let the code get moved to prod without completing the testing in QA.

DR (Disaster Recovery) – Just as it sounds this is a back up to production so if any new code impacts prod you can use this to perform a quick roll back to the previous version.
Each of these environments is used for specific reasons and a few guiding principles on each one are below.

Understand your environments

Image source: http://graphicdesign.stackexchange.com/questions/15788/examples-of-well-designed-software-architecture-diagrams

Use the architectural drawings to understand your environments. This gets difficult when working on complex environments because you have 50 boxes pointed at 50 other boxes but it is very important to understand what they limitations of the test environment are. For example if you have a test environment that is faking a call to send data back and forth, you need to make sure people understand your testing will not include this validation and acceptance of the risk and separate validation of that call would have to take place.

Understand the Purpose

When you say I cannot test in production or dev someone will ask why. To be able to reasonably justify why that is a horrible idea you should keep in the back of your mind why you are using these environments. For example the purpose of a disaster recovery environment is very different than a sandbox environment.

Understand the Process

All code updates should follow a specific process. You will likely not have to worry about it since someone else will own the process. Updating the code is not as simple as moving the code from DEV to QA to PROD. All of the environments will have to be updated to keep everything up to date. Also identify if the environments will be used for multiple projects. If those projects do not have the same end date you will have to understand how the effort can be tested together.

Stay In Your Lane

One final note about environments, when the testers identify a defect there will be times where you will see an issue that only appears in QA (the testing environment). Though the developer would prefer for you to sign off that it is not a real defect because it is not seen in the development environment, you will not be able to. You have to keep within your own environment. If you do not, a defect that appears in the testing environment will then go into production (the client facing environment) and someone will ask you (in a less than kind way) why you let a defect get released into production since it obviously occurred within QA. No one will ever ask why a defect in the developer environment made it to production because QA’s environment (unlike development’s environment) will be closest to a production like environment

About the author

Richard Ellison is the Director of The QA People. The QA People is a company focused on creating social mobility through software development with a focus on offering opportunities for people from various backgrounds to enter into software testing positions through workshops and online classes and certifications. Rich has worked as a QA and Project Manager Consultant in various industries such as health care, insurance, automotive and financial. His current book “How To Be A Tester” is available on LeanPub at https://leanpub.com/howtobeatester.