Why Your QA Team Needs A Dedicated Environment For Testing

Ever since the adoption of Agile methodology we have witnessed a debate over the topic of having a dedicated Staging environment for QA practices. In this age of rapid web-app development, creating a staging environment and maintaining is often considered to be a wasteful and strenuous task.

Those familiar with enterprise development would laugh at this idea (they have 4-5 different environments, which carry their own burdens). But for a QA working in a startup, this is still one of the most asked questions – Why do we need a separate environment for Quality Assurance when we have a local Dev environment already set up for developers to test? Just test on the developer environment before making changes into Prod? Why should we restrict multiple teams by making them share a dedicated environment? Why should we spend more money resources on another testing environment?

The role of the Staging environment is presumed to be obvious in large enterprises. However, in enterprises, it is considered to be so apparent in any architecture that nobody cares about explaining it. Some just take it at the face value as just one of the quirks of working with a big company. As a result, many experienced QA as well ends up doing it in an erroneous way and some of us end up neglecting it entirely. Those who implement forget about the intent behind doing so– as they build it just because everybody said it’s a best practice.

So here’s my attempt to remind everyone why staging environment is so important for small and big companies alike.

What is a Staging environment?

People reply to that question with varied definitions. Some would say “it is a copy of production”.”An environment similar to prod but without any customer.” I define it as a mirror environment meant to mimic production as precisely as possible for quality assurance. I consider it to be a Goalkeeper, standing tall as the last line of defense between the bugs brought in by the recent release process and the production environment.

And before you ask, Yes, a staging environment should have a complete simulated copy of databases as well. You will be clear about my perception as you read further down this blog.

Why do we need a Staging Environment?

Sense of Reliability – Staging environment helps in ensuring the reliability of our code, pipeline, infrastructure & overall product.

Test cases can never suffice – People presume that good test cases are enough for quality check. However, they aren’t! Test cases are derived from user stories. User stories are scenarios thought of by testers, as they put themselves into the shoes of the end-user. Even if you have a team of sound engineers and quality analysts, it is not possible to anticipate every single way in which your product would be used by thousands or millions of your customers. Especially, in terms of User Interface.

Hastens Disaster Recovery – If a recent release is causing disruption of service in your product then you can roll back to the previous version with a lot less to worry about. This is vital if you are offering a SaaS where one outage could result in losing a large number of valuable customers. Every service if made to deploy through a common pipeline then various teams can push one another’s code if needed, allowing the team to perform disaster recovery plans more rapidly.

Dev Environment is ever-changing – With Agile Scrum Development, the demands of end-users are ever-changing, increasing fluidity in terms of the state of a product. It becomes nearly impossible for a QA to find a time window for performing a complete round of regression testing. Also, the tools used by a developer could prevent a QA validation to take place in an appropriate manner. A developer’s main focus would be on delivering functionality and not quality. As brutal as it may sound, it holds true for a majority.

Who should build a Staging Environment?

As a Staging environment is supposed to be a twin of the Production our first instinct would tell us to yell QA(Quality Analyst) as an answer to this question. But it would be wrong! It should be done in a manner as proper as you imply in production. Assemble your infrastructure team to generate a platform that later gets filled with services by the developers.

While building a staging environment it is vital to develop a separate server as well as a database for Staging environment.

Staging server – A separate dedicated server meant for facilitating testing for a website by hosting a staging environment.

Staging database – A database that is replicated from production to maintain a staging environment as close to production as possible.

Best Practices for Software Testing

Most of the times a web-app workflow comprises of 3 environments dedicating one for each team: Dev, QA a.k.a Staging & Prod in your product workflow.

Workflow:

• Developers are free to apply fix on existing bugs in any way they deem efficient in the local Dev environment.
• Developers perform unit testing for the validation of the latest feature implemented by them.
• Once unit testing is successful, the feature is pipelined into Staging or QA for testing and quality assurance.
• Staging is where regression testing takes place to make sure that recent features are applying fix to the problems without disturbing any other functionality of the existing application.
• Release date arrives and the features who passed with flying colors in Staging environment are migrated to Production.

Now that we have a good understanding of the workflow. It is time to deep-dive on best practices.

DEV LOCAL Environment – DEV environment allows developers to make code changes into the application for fixing an existing bug. Once the fix is applied it is unit tested by the developer. We already know by now that testers are not advised to perform testing in DEV.

Integration Testing Environment – When different bug fixes related to different modules are done with successful unit testing then integration testing is performed. This environment is where all different modules are integrated and hit with a plethora of test cases to bring the code up to speed after integration.

SANDBOX – They say “Necessity is the mother of innovation”. This playground for developers is where innovation rises in the form of code to meet the necessity. This is of no use to a tester.

STAGING Environment – By far I hope we are all pretty aware of what it does. A pre-prod deployment area that serves a quality assurance check by providing a platform almost identical to Production. Sometimes when we are in a hurry to deploy immediate fixes, we tend to miss them out on this environment after integration testing. This is not a good practice. Make sure you migrate everything and test into Staging to be safe. Remember, staging is the closest twin to prod.

PARTIAL PRODUCTION ROLLOUT – Develop a rollout plan for thorough testing in Production, including the following mentioned major areas related to code migration:

• Canarying
• Monitoring
• Exploration
• Distributed Tracing
• Dynamic Instrumentation
• Feature Flagging
• Exception Tracking
• Traffic Shaping
• A/B Testing
• Chaos Testing
• Profiling
• Teeing
• Load Testing
• Shadowing
• Load Testing
• Usability Testing
• Cross Browser Testing
• Accessibility Testing

Production – After validation in QA environment you push your changes to Prod. Go-live environment that is used by your customers. This environment is not to be messed with! A developers without proper approvals cannot implement any change in it, not even a minor fix is advised without a relevant sign-off.

Disaster Recovery – This is where you keep a backup ready of your Production before making any change into it. If things go south you can execute a rollback to the previous version in a fly.

But you can’t always roll back! For instance, If you are coming up with a release that brings with it a new database structure which is conflicts with your previous release associated database then rolling back would be catastrophic and may even shatter your application.

Concluding

I would like to personally advise the testers to mind their own business. The argument between a tester and a developer can go on for quite some time. So if you go up to them after testing a bug in Staging, which they aren’t able to reproduce in DEV then don’t let them convince you to let it go with your sign-off. Keep this in mind! If the changes go live into production, and even by a thin possibility the bug rises in Prod then the management will be expecting a solid explanation from a tester and not a developer.

This must have been a lot to dig in. The pipeline workflow may seem weary but it is well worth it! At the end of the day you deliver a robust product, which is rigorously tested. Providing a sense of relief as you know that you will be a lot far from outages that may wake you up in the middle of the night for an unknown scenario.

It is a virtuous cycle.
Validate your changes on Staging → Deliver a stable product → Retain your customers → Increase brand awareness → Increase your revenue → Invest more for a better Staging environment.

Related Post: What Is Holding A Software Tester From Finding Bugs?