A project environment does not necessarily correspond to a distinct physical server. Rather, it is a logical environment made up of a database and a copy of the software.
Project environments are like test tubes in a laboratory. We control their content, we log the changes we make, and we record the results of tests that we conduct. As the project progresses, environments resemble the production environment more and more closely.
The testing strategy for a major project requires, on average, the 10 environments. Let’s present some of those environments here.
Project environment #1: Functional sandbox
This environment is used by software and business experts to conduct tests without any danger of compromising work in progress in other environments. Here, one can make changes and conduct tests before applying the changes in other environments.
#2: Functional test
Generally, there are two functional test environments that are active simultaneously throughout the following test cycles: the two functional test cycles, the data conversion cycles, and the two integrated test cycles. These environments are used by software and business experts.
Two development environments are required. The first is used to develop data-conversion programs: the database in this environment is frequently emptied and reloaded. The second environment is more stable than the first, making it possible to test interfaces, reports and screens without having to deal with the database fluctuations of the first environment.
Project environment #4: Technical sandbox
This environment enables technical experts to test software, corrections and patches without the risk of damage to the work of other teams because applying a patch often generates additional problems. Once testing of a patch is complete, the technical experts can install it safely in the other environments.
At the start of the project, this environment is used to train project teams. Subsequently, it is used to train users. A separate training environment means that the database can be reloaded prior to each training cycle, enabling trainers to reuse the same examples and allowing users to reuse the same exercises during their practical work.
This environment is a benchmark that contains all the parameters of the applications included in the scope of the project. The other project environments are created by making copies of this environment. The configuration management process is used to promote and log changes to parameters coming from the test environments. One of the main purposes of this environment is to be used in creating the production environment, which makes the process of going live more efficient.
Project environment #7: Certification
The project team manages all the project environments except the certification and production environments, which are managed by the operational team. The project team hands over all the components of the solution to the operational team, who install these components in the certification environment and check that they function correctly before installing them in the production environment.
This is the environment that users access to use of the new solution. This environment cannot be accessed by the project team.
Variations of the environments set out here may be necessary depending on the nature and scope of the project.
You could also like this post : Testing strategy for enterprise software : a risk-management approach
Jean-François Desroches is Program Manager at PlanAxion Solutions.
He can be reached at email@example.com