Test Environment Management Approach Ensures:
- Test Environments available on time
- Resolving environment-related issues
- During Test Planning, request the environment to build any new environment/ Refresh the existing environment for Testing for new teams.
Touch points between the QE team and Environment Management Team
Two significant touch-points for test teams with the Environment management team are
Request for building a new test environment
Raising issues with test environments
Touchpoint in the Test Planning & Execution phase
The QE team should place an Environment Booking request with the TEM team to book environments for the testing period. This request should contain the information TEM Team requires to build the necessary environment(s).
The TEM team refers to the Master Landscape plan to book the request of the QE team and make any modifications to the environment if necessary. In environmental conflicts, the concerned teams are notified, and the conflict is resolved.
The touchpoints during execution will be checking on environment health once the environment is available and the code is deployed & before execution starts.
Smoke Testing
When the test environment is available, and the code is moved to the environment, the QE team should execute a smoke test to ensure that the test environment meets their requirements. This will ensure complete system coverage and provide confidence to proceed with full-scale testing. The testing team will proceed with further testing in the build only if Smoke Testing is completed without any failed test cases.
If the build is broken / not compiled / smoke testing fails, please inform the Development Manager as soon as possible. If there is a problem with the initial environment, this should be brought to the notice of the environment management team so they can resolve it. This is done by raising a defect and assigning it to the TEM Team.
Issues during Execution
While performing test execution, the test team should raise the defects for the test environment-related issues during the smoke testing phase, providing as many details as needed and possible.
The defects should be assigned to appropriate teams (Configuration, Data Migration, SI, Legacy Apps etc., as appropriate.
There should be a suitable escalation mechanism defined to escalate issues when needed
Test Environment Segregation
| Environment | Sub Environment | Usage |
|---|---|---|
| Development(Local) | This is the working environment of individual developers, or individual teams. The purpose of this environment is for the developer/team to work in seclusion from the rest of the team, enabling them to make and validate changes without having to worry about adversely affecting other developers. These environments are likely to have their own databases to enable regression testing in an agile framework. | |
| Development Integration(DEV) | Each team should have its own integration environment, often referred to as a build environment. Developers promote their changed code to this environment, test it, and commit it to their team configuration management system. The goal of this environment is to combine and validate the work of the team (squad / initiative) so it can be tested before being promoted into the QA test environment. | |
| Quality Assurance(QA) | QA QA Ing QA Perf QA UAT |
The QA environment is shared by several (squad) teams. This environment is often referred to as a pre-production sandbox, a system testing area or simply staging area. Its purpose is to provide an environment that simulates your actual production environment as closely as possible to test the application in conjunction with other applications. |
| Pre-production(Pre-Prod) | Pre-production is a staging environment that closely mimics the production environment. If a code change is needed quickly to go live, it should be put on this environment where automation can verify that the fix did not break anything else and that the fix actually works. It should also be used for the last phase of acceptance & performance testing. |
Environment Readiness Checklist
| # | Questions |
|---|---|
1 |
Has the scope of testing been identified? i.e. application/product and its interfaces to external applications. |
2 |
Has the deployment environment or platform of the applications/products and that of the external application been identified? |
3 |
Is the connectivity established between applications/products, interfaces and respective databases? |
4 |
Are the databases (version) connected to the respective application and interfaces? |
5 |
Are the application/product database objects and the external application in-scope of the testing identified? Are the database objects segregated as stored procedures, views, tables and triggers? |
6 |
Are the database tables differentiated as:
|
7 |
Are the baseline sources identified - required for testing? (Create the QA environment on relevant platforms and load baseline sources. Compile and create executable versions.) |
8 |
Is the connectivity established between databases and applications? Connect applications under test to external applications. |
9 |
Do you know if the Smoke Test is carried out to ensure the entire setup is ready for testing (test only for Business critical transactions)? |
10 |
Do you know if the operational data used during the smoke test was cleaned up? (Back up the entire environment & database and baseline them) |
Test Environment Management Tracking Metrics
Number of environmental issues raised/resolved/escalated
Aging of issues
RACI for Test Environment Management
| # | Tasks | Quality Engineers | RQM | TEM Team | Dev Team |
|---|---|---|---|---|---|
| 1 | Raise requests for new test environments | R | R/A | I | C |
| 2 | Raise defects/incidents for test environments related issues | R | A | I | C |
| 3 | Perform smoke testing on the new test environment built | R | A | I | I |
| 4 | Verify whether environmental issues are resolved | R | RA | C/I | |
| 5 | On resolution of issues, inform the relevant team. | R | R/A | I | I |
| 6 | Demand/supply management of test environments in the region | C/I | C/I | R/A | C/I |
| 7 | Capacity planning for the region | C/I | R/A | C/I | |
| 8 | Build test environments | I | I | R/A | I |
| 9 | Control security of the test environments | I | I | R/A | I |
| 10 | Resolve issues with test environments | C/I | C/I | R/A | I |
| 11 | Track/close the tickets related to Environment Management | I | R/A | I | |
| 12 | Resolve escalations related to environments, if any | I | C/I | R/A | C/I |
| 13 | Deploy Applications into Test Environments | I | I | R/A | C/I |
