TEST ENVIRONMENT MANAGEMENT
Doris Robinson
Test Conductors LTD
WHAT IS TEST ENVIRONMENT MANAGEMENT?
Test Environment are typically built with specific functionalities suitable for running checks and balances against
a developed solution. They act as a test bed in verifying software or application design. These functionalities
would include solution under test requirements and the integrated ecosystem landscape an organisation has in
order to effectively validate the new system does not damage the organisation production environment.
The view in IT is that Test environments differ with those of production environments in terms of operating
systems, integration links with live 3rd party systems, patch levels, software versions, configuration, etc. this view
has given room for increasing gap between test and production environments management. Which has
increased the chances of an application failing after being deployed or a defect leaking into live systems.
Poorly defined management procedure and asset control necessitates high investment for environment
infrastructure, as part of the solution verification, testing teams can utilize test stubs or test drivers to ensure
test coverage are effectively executed.
 A Test Stub – Is a temporary replacement module used in order to test aspect of an application that are not
yet available or developed. It usually calls the piece of the missing code in a top down approach.
 A Test Driver - Is similar to a Stub but from the bottom Up, it is used to verify integrated systems low level
components that are not yet ready for testing but needs be verified or called on as part of an integrated
interface system testing.
ENVIRONMENT TYPES
Different organisation creates the need for various environment depending on cost, the amount of projects and their demand capacity management portfolio.
Typically within environment management you will find the below types of environment as standard;
 Development – Dev.. This is a developer’s environment were design build activities are carried out, unit tested before been promoted to an actual test
environment;
 Sandbox – Anyone with access and login rights can develop their application knowledge and self test their codes or various design to ensure it works before
moving/building the specific component in dev. Just as the name implies it is a playground area to try several development techniques to establish build
confidence;
 QA – This is the initial environment in which system or application under test should be promoted to after development work is complete. The system or
application an organisation could decide to implement one or more QA environments which does not necessarily have to be fully integrated but the level of
systems should be suitable enough in order to basically test the requirement been developed;
 Pre Prod – An environment which should be built as almost identical to a production environment, same infrastructure, same application, master &
transactional data sets; full integrated systems and application to ensure new solution are regression tested to validate co-existence with existing system
landscape before promoting the solution to a live environment. The only difference between this environment and production is that it should not transmit
real transactions or information to live customers;
 Production – This is a real live environment with real transactional flow of data, real customers carrying out day to day operational business services activities.
When there are some potential critical hot fixes that must be directly deployed into production a retrofit on other environment should be performed. A
detailed rollback procedure should be in place to ensure the ability of restoring an environment to it’s last good state.
 BAU – As business operations becomes more rampant and business request changes from production, a dedicated test environment to ensure issues are tested
separate from actual project codes or transports releases are becoming more rampant;
 DR – An environment dedicated to run disaster recovery test in ensuring that the system/ecosystem landscape does have the ability to sustain potential or
system failures in an event where there is possible fallout. More and more organisations are not able to effectively establish a fully functional DR test
environment as the cost on both human and infrastructure resources in maintaining such environment is huge.
Testing teams has a vested interest in ensuring test environments are built to specification of the application or system under test in order to ensure the verification,
validation and acceptance criteria are successfully met. Their contribution towards provisioning activities and performing environment’s smoke or shakedown test
provides assurance that an environment is built appropriately.
The build process of an environment depends on the complexity of the application under test or project requirements, this can either be created from a new state
or refreshing a previous environment by ensuring the necessary application or system interfaces are enabled, required jobs, up or down streams systems are
enabled or disabled based on requirements.
A well thought out test environment management practice to support the verification of production issues should be effectively built to function in the same
capacity as hat of production. Due to cost of maintenance and resources, organisations struggles to justify to have test environments that are replica of production,
it is evident that having a single test environment as close to production improves the quality verification process.
Here are some of the ways in ensuring a test environment is provisioned correctly:
1. Business, QA and Testing teams take part in the requirements and built definition of the environment
2. Have a clear understanding and knowledge management of solution delivery by continuous engagement with project or programme office in understanding
requirements and demand for testing teams
3. Ensure the various ecosystem landscapes are fully integrated not just in production but in Pre-Production environment
4. The appropriate data sets; master or reference data from source systems (Production) with adequate volumes should be loaded into the environment to
enhance the test verification process.
5. Ensure the data required in test environment are in the appropriate format based on testing requirements – sanitised, anonymous/ scrabbled or real
production data are loaded in the relevant test environment
6. The security roles, user profile/access rights for testers and business users are clearly defined, created and provided
7. Perform a smoke/shakedown test to verify that the environment is truly ready for the start of testing
8. Ability to create new test environment, setup refresh mechanism and provide technical support to the testing teams - Refresh an environment using the LEAN
approach to accelerate the process of loading targeted data from production into a test environment based on changes to a specific application rather than
refreshing the entire ecosystem landscape
9. Ability to scale a test environment infrastructure from on premise to possible cloud service to support application development and testing demands
PROVISIONING TEST ENVIRONMENT
TYPICAL ENVIRONMENT “PATH TO LIVE” PLANNING
MANAGING THE “PATH TO LIVE” PROCESS OF TEST ENVIRONMENT
 IT or the project teams should provide dedicated technical support during testing to ensure test environment are built and issues are
resolved appropriately during testing phases.
 We have seen or heard in technology projects when poor test environment configuration or utilization has either cost the project go
live date delays or resulting in a cancellation of the entire project.
 One of the testing bed rocks in achieving quality is ensuring that the test environment are built with the knowledge of both current
and future system landscape. This is important to validate the system under test and to verify that the new system is able to
integrate to the entire ecosystem of the organisation.
 It is imperative that projects have a set out procedure to create, manage and maintain test environment. Most organisations struggle
with the idea of having a core testing team for starters and its equally the same when it comes to having a dedicated team
responsible for end to end delivery of test environment. Testing teams are constantly being informed by IT that the priority is not to
manage test environment but production environment, least they forget if test environment are built, maintained effectively and
systems/application are tested in an adequate robust environment then there will be less issues found in production to support.
 More and more IT organisations are now taking the need to have test environment management (TEM) processes and procedures in
place seriously, as this does have an underpinning success of how business view application and system delivery.

What are the common Test Environment today

  • 1.
    TEST ENVIRONMENT MANAGEMENT DorisRobinson Test Conductors LTD
  • 2.
    WHAT IS TESTENVIRONMENT MANAGEMENT? Test Environment are typically built with specific functionalities suitable for running checks and balances against a developed solution. They act as a test bed in verifying software or application design. These functionalities would include solution under test requirements and the integrated ecosystem landscape an organisation has in order to effectively validate the new system does not damage the organisation production environment. The view in IT is that Test environments differ with those of production environments in terms of operating systems, integration links with live 3rd party systems, patch levels, software versions, configuration, etc. this view has given room for increasing gap between test and production environments management. Which has increased the chances of an application failing after being deployed or a defect leaking into live systems. Poorly defined management procedure and asset control necessitates high investment for environment infrastructure, as part of the solution verification, testing teams can utilize test stubs or test drivers to ensure test coverage are effectively executed.  A Test Stub – Is a temporary replacement module used in order to test aspect of an application that are not yet available or developed. It usually calls the piece of the missing code in a top down approach.  A Test Driver - Is similar to a Stub but from the bottom Up, it is used to verify integrated systems low level components that are not yet ready for testing but needs be verified or called on as part of an integrated interface system testing.
  • 3.
    ENVIRONMENT TYPES Different organisationcreates the need for various environment depending on cost, the amount of projects and their demand capacity management portfolio. Typically within environment management you will find the below types of environment as standard;  Development – Dev.. This is a developer’s environment were design build activities are carried out, unit tested before been promoted to an actual test environment;  Sandbox – Anyone with access and login rights can develop their application knowledge and self test their codes or various design to ensure it works before moving/building the specific component in dev. Just as the name implies it is a playground area to try several development techniques to establish build confidence;  QA – This is the initial environment in which system or application under test should be promoted to after development work is complete. The system or application an organisation could decide to implement one or more QA environments which does not necessarily have to be fully integrated but the level of systems should be suitable enough in order to basically test the requirement been developed;  Pre Prod – An environment which should be built as almost identical to a production environment, same infrastructure, same application, master & transactional data sets; full integrated systems and application to ensure new solution are regression tested to validate co-existence with existing system landscape before promoting the solution to a live environment. The only difference between this environment and production is that it should not transmit real transactions or information to live customers;  Production – This is a real live environment with real transactional flow of data, real customers carrying out day to day operational business services activities. When there are some potential critical hot fixes that must be directly deployed into production a retrofit on other environment should be performed. A detailed rollback procedure should be in place to ensure the ability of restoring an environment to it’s last good state.  BAU – As business operations becomes more rampant and business request changes from production, a dedicated test environment to ensure issues are tested separate from actual project codes or transports releases are becoming more rampant;  DR – An environment dedicated to run disaster recovery test in ensuring that the system/ecosystem landscape does have the ability to sustain potential or system failures in an event where there is possible fallout. More and more organisations are not able to effectively establish a fully functional DR test environment as the cost on both human and infrastructure resources in maintaining such environment is huge.
  • 4.
    Testing teams hasa vested interest in ensuring test environments are built to specification of the application or system under test in order to ensure the verification, validation and acceptance criteria are successfully met. Their contribution towards provisioning activities and performing environment’s smoke or shakedown test provides assurance that an environment is built appropriately. The build process of an environment depends on the complexity of the application under test or project requirements, this can either be created from a new state or refreshing a previous environment by ensuring the necessary application or system interfaces are enabled, required jobs, up or down streams systems are enabled or disabled based on requirements. A well thought out test environment management practice to support the verification of production issues should be effectively built to function in the same capacity as hat of production. Due to cost of maintenance and resources, organisations struggles to justify to have test environments that are replica of production, it is evident that having a single test environment as close to production improves the quality verification process. Here are some of the ways in ensuring a test environment is provisioned correctly: 1. Business, QA and Testing teams take part in the requirements and built definition of the environment 2. Have a clear understanding and knowledge management of solution delivery by continuous engagement with project or programme office in understanding requirements and demand for testing teams 3. Ensure the various ecosystem landscapes are fully integrated not just in production but in Pre-Production environment 4. The appropriate data sets; master or reference data from source systems (Production) with adequate volumes should be loaded into the environment to enhance the test verification process. 5. Ensure the data required in test environment are in the appropriate format based on testing requirements – sanitised, anonymous/ scrabbled or real production data are loaded in the relevant test environment 6. The security roles, user profile/access rights for testers and business users are clearly defined, created and provided 7. Perform a smoke/shakedown test to verify that the environment is truly ready for the start of testing 8. Ability to create new test environment, setup refresh mechanism and provide technical support to the testing teams - Refresh an environment using the LEAN approach to accelerate the process of loading targeted data from production into a test environment based on changes to a specific application rather than refreshing the entire ecosystem landscape 9. Ability to scale a test environment infrastructure from on premise to possible cloud service to support application development and testing demands PROVISIONING TEST ENVIRONMENT
  • 5.
    TYPICAL ENVIRONMENT “PATHTO LIVE” PLANNING
  • 6.
    MANAGING THE “PATHTO LIVE” PROCESS OF TEST ENVIRONMENT  IT or the project teams should provide dedicated technical support during testing to ensure test environment are built and issues are resolved appropriately during testing phases.  We have seen or heard in technology projects when poor test environment configuration or utilization has either cost the project go live date delays or resulting in a cancellation of the entire project.  One of the testing bed rocks in achieving quality is ensuring that the test environment are built with the knowledge of both current and future system landscape. This is important to validate the system under test and to verify that the new system is able to integrate to the entire ecosystem of the organisation.  It is imperative that projects have a set out procedure to create, manage and maintain test environment. Most organisations struggle with the idea of having a core testing team for starters and its equally the same when it comes to having a dedicated team responsible for end to end delivery of test environment. Testing teams are constantly being informed by IT that the priority is not to manage test environment but production environment, least they forget if test environment are built, maintained effectively and systems/application are tested in an adequate robust environment then there will be less issues found in production to support.  More and more IT organisations are now taking the need to have test environment management (TEM) processes and procedures in place seriously, as this does have an underpinning success of how business view application and system delivery.