Critical in the software development lifecycle is the presence and maintenance of application environments - the locations where developers do their programming, testers perform their software quality assurance, and members of the wider team can access the latest version of the app for their own needs:
An environment includes both the physical hardware and software components to allow the application under development to run properly, as well as the application itself. Environments are typically a self-contained cluster of servers isolated from other environments (or "sandboxed") ensuring the code is in a known state for further work.
Let's look at the typical array of application environments utilized during application development:
Developers create and debug their initial code on their local machines. To facilitate their development and unit testing, developers may use stubs to simulate other pieces of software like a database or web service. The local environment is under the full control of the individual developer because:
For instance, consider an e-commerce application. The application interacts with web services like a payment gateway to verify a credit card. In a local environment a developer can write the code for the web application against the stubbed credit verification software to facilitate coding as well as unit testing on their local machine.
Just as the local environment is for the individual developer to program and debug locally, the "development" environment is the shared location for all developers to check their code against all the changes in that release. This is known as integration testing and a common practice nowadays is to automate these tests such that after code is updated to the repository, the application automatically builds and (assuming no errors upon building) the integration tests automatically executed.
One thought to reduce the number of environments is to have the QA engineers use the dev environment for testing. This is a bad idea because:
Continuing with our example of the e-commerce application, the structure of the development environment would be similar to that of the local environment except that the versions of all components would be the latest “tip” version.
Stable versions of the build are then released to the QA environment for thorough functional, integration, regression, and other types of testing. This environment can be further managed by splitting it into two separate environments, QA and Pre-Production, for specific purposes. Note that these terms (QA, Staging, and Pre-prod) are fairly fluid and may be used interchangeably on different teams.
The bulk of the application testing effort occurs in the QA environment, and the bugs logged refer to issues found in this environment. It is an important step on the path towards the software release readiness, and a separate and controlled environment is critical because:
In our continuing e-commerce application example, the QA team tests it with the web services and the database.
As the application moves towards greater stability, testing is conducted in the Pre-Production environment where the infrastructure is as identical to Production as possible. Having this separate environment is useful for the following reasons:
The Production environment is where the users finally get to enjoy the latest released code and enhanced functionality, such as our e-commerce application with web services and databases, and integrations with external services like credit verification.
It goes without saying the production environment must work smoothly and without issues in order to provide a pleasant end-user experience. While successive builds of the application are being tested in dev and QA, the app continues to run unaffected in production.
It should be obvious that having a clear and concise set of environments is critical for an efficient and successful software development lifecycle, from development, through QA, and into production. Getting each environment up and running and the handoff processes from one environment to another is critical to a well-run QA process. For a limited time, OnPath Testing is offering a complimentary QA Audit to examine your processes, and I encourage you to contact me at email@example.com to learn more and ensure your testing is on the right path.