Test Environment Management (TEM)

MethodiQA’s Test Environment Management solutions caters for integrated portfolios and Projects operating in complex integrated test environments. Powered by Plutora, our capability marries the best practices of industry recognized ITIL and DevOps concepts. By right focus on communication and collaboration among the various delivery teams and stakeholder groups we ensure that your test environments are made available, fit for purpose and stable. Our service offerings include:


Environment Planning and Scheduling

A consolidated timeline view of project releases / activities scheduled and approved in the environments across the respective test instances. The Environment Schedule provides an insight of test environment state of allocation and potential clashes within a release or across releases
MethodiQA implements management of Environment Planning and Scheduling functions in conjunction with its elegant Environment Booking and Allocation processes. This enables the organisation to plan optimal usage of its test environments and be able to address some of the below but not limited to challenges, within the organisation:

  • Lack of transparent systems/processes to log test environment bookings – With multiple projects, enhancements and break/fix releases competing on a subset of test environments it is crucial that all releases use a unified method to capture the test environment bookings required for their different release phases. MethodiQA’s Environment Booking process ensures that requirements are done in a consistent way across the various releases and with sufficient lead time for the analysis and formal approval of the bookings.
  • Conflicts arising in test environment allocations among projects –  Having captured the test environment bookings across the different releases, conflicts are soon likely to emerge. Several releases/release phases have overlapping environment bookings. The question then is to resolve this conflict and address who gets the approval and who gets knocked back? MethodiQA’s Environment Approval and Allocation dives deep into the usage for each environment for the particular release to determine if a test environment can be sharable, time sliced or dedicated, in tandem with other release metrics to resolve conflicts and approve allocations. In case of hard conflicts value based analysis is performed to determine the priority release.
  • Inability to perform Systemic Impact analysis in the event of Release Re plan – Changes are inevitable. Release scope and schedule Change Requests needs to be impact assessed by Environment Management. But how? With many test environments already allocated to other releases and shifting timelines, impact assessment can soon become a difficult as well as very time consuming task. MethodiQA’s Environment Impact Analysis methodology streamlines the process and makes it easy to understand the impact of such delays to other releases and take actions accordingly.

Environment Schedule:

Plutora Environment Schedule 3

Fig1: Environment Schedule shows the environment allocation by Projects, green bars show approved allocations vs yellow pending approvals

Environment Booking Request:

Plutora TEBR
Fig2: Environment Booking Form enables to log environment requirements formally for a specific release/release phase into a single centrally stored and transparent repository

 


Environment Service Management

Test Environment Management capability provides a number of services to a several organisational stakeholder groups. The likes of Architects, Developers, Testers and Business Configuration teams all require changes to be implemented, users to be provisioned, key decision information to be communicated. There are also inevitable incidents that have to be managed and service restored to minimise impact to the Testing and Release. While traditional IT Operations Service Management framework like ITIL are way too heavy and cumbersome to a dynamic project and release environments, MethodiQA implements a fit-for-purpose, scaled down Environment Service Management framework that provides a good balance between agility and stability. The adoption of Environment Service Management framework ensures the below challenges are catered to:

  • Slow turnaround of Environment related change requests (TECRs) resulting in project delays – With high capital expenditure and daily burn rates, projects are heavily reliant on expedited change control and implementation of Environment work requests. MethodiQA implements ‘light-on’ change control process on Environment Requests whilst constantly monitoring the queues for progression and closure of work items. The change control acts based on the principal of requestor/approval matrix. The responsible change approvers, based upon each test environment/release phase provide quick approvals before actual changes are implemented. Powered by Plutora, a leading cloud based Environment and Release Management software, MethodiQA set-ups a nimble yet controlled Environment Requests process which is light yet transparent and fully traceable.
  • Environment outage, stability and performance issues resulting in significant project delays   Environment incidents can originate from inherent infrastructure or application level issues as well as impacts caused post the implementation of environment configuration changes. In either case, the result is likely to translate to project release schedule slippage and financial stress. MethodiQA implements Environment Incident and Problem Management Process where incidents are easily captured and communicated to environment team for resolution. Repeat incidents are dealt via Problem Management process where root cause analysis and fixes are implemented. High Impact incidents and their expected Mean Time to Repair are communicated to the appropriate users groups via outage emails ensuring they are in the know.

Environment Change Request Dashboard:

ecr-dashbord
Fig3: Environment dashboard showing the request queue, summary of open vs completed requests and a trend line of work throughput delivered over a period of last 6 months

Environment Change Request:

ecr
Fig4: A sample Environment Change Request with configurable workflow for intermediate reviews and approvals shown on top


Environment Interface and Integration Management

Interfaces form critical components in the likes of System Integration, User Acceptance Testing, End to End test phases. Owing to the fact that not every production application component has its test environment instance available, provisioning of the associated interfaces can very quickly become a nightmare. The testing requirements do not necessarily articulate their interface requirements which calls for a seasoned environment management team who can work with the testing and provide professional consultation to elicit their requirements and spell those clearly. These requirements then need to be analysed and then identify the optimal solution which can be:

  • re-using existing components by intelligently un-hooking from an environment group and re-integrating into another environment group, OR
  • identifying interfaces that can potentially have common endpoints and using the applications in a shareable manner, OR
  • in other instances, leveraging an often under-utilized internal capability within an organization to develop suitable Stubs and Drivers which mimic the original functionality

If done right, the above can dramatically bring down the cost/time of delivering a fit for purpose environment.
fig-5
Fig5: Illustration shows the list of interfaces available in the selected Environment group and other related information
fig-6
Fig6: Illustration shows a visual map of the environment components and the connectivity patterns, interaction methods implemented


Environment Software Configuration Management

MethodiQA implements and manages Software Configuration source code and/or deployable artefacts for each development stream in the project ensuring that each code branch is being properly controlled and labelled. Thus building technical capability to deploy different intermediate baselines of code drops in any given test environment. These releases of software can in turn be easily recreated from the software repository as required hence making it possible to articulate the differences between various code drops


Environment Software Deployment Management

MethodiQA implements and manages a clear and reliable Holistic Software Deployment process. While a software deployment can be very complex and comprise of multiple technical scripts, human interaction tasks and multiple inter-dependencies within, our processes ensure that the consumers and stakeholders of these releases are also in the picture – no matter how technically successful code the deployment is, it is doomed to fail without the due care of approval processes, identification of specific test environment instance, a clear set of release notes and stakeholder notifications throughout the course of the change implementation.


Environment Code/Config Retrofit Management (SCM)

Implementing software configuration management across environment landscape, progression path and ensuring appropriate control measures are in place to allow testing against the latest production code base, thus averting the below challenge scenarios and many more:

  • Releases override pre-existing production configuration – It is not uncommon for projects to have introduced a release into production which have caused an existing feature or functionality to regress. Although in theory regression testing prior to go-live should have picked these defects reality is that due to time pressures and resource constraints these defects often go undetected. To eradicate this scenario MethodiQA implements Environment Code and Config Retrofit process. By spelling out the code progression path across the various test environments, the target test environments can be easily identified for production code and config retrofits. The production change candidates are then selected for their applicability to be either retrofitted or merged to the different test environments.
  • Invalid testing caused by incorrect environment software configuration – Flexibility is also the enemy in loosing track of what is actually deployed in each and every test environment. MethodiQA’s Deployment matrix clearly articulates the different release levels across the different application verticals in each test environment. Knowing the release baseline is crucial for the Defect Management i.e. a defect must be attributed to a specific release ID and a defect fix must also be attributed to a later release ID ensuring that testing is performed adequately.

fig-7
Fig7: Illustration shows the code retrofits or merge from continuous changes released to Production back into the Project Test Environments