There is a particular group of QA specialists who are absolutely sure that the practice of testing in production is not very good: it doesn’t help to prevent the appearance of bugs for end customers but simply states their presence. Also, a tester needs to leave the usual workflow and methods of testing which he/she uses on a daily basis.

What’s the point in quality assurance in production if everything looks great and works properly in staging?

Usually, the process of software development needs some virtual environments where a web product can be simultaneously developed and tested.

A typical system of software testing means creating a separate environment, in most cases, it’s called [highlight dark=”no”]QA environment[/highlight](staging) where you can normally check the improved or redeveloped functionality and be sure that the bugs won’t appear to end-user.

When do we need testing in the production environment?

Difficulties in distinguishing the staging and production environments

Staging often seems to be a primitive copy of the production environment and is not visible to an end-user but is completely similar to a final version of a product. When the software is very complex and huge, the technical support of such a web product becomes quite a hard and expensive process (and we can’t always find the sense in such a process).

For example, we have a project which uses long test scripts for functional testing of the staging environment. It does not have the same technical background to the production environment but this doesn’t interfere with performing functional testing.

Why can’t we simply copy the production environment to staging? The answer is very simple: can you imagine how many resources we need to copy such a thing as Facebook, for example, with all its powerful and productive servers. Actually, you have to deploy a copy of such an application. It’s extremely expensive.

We should also mention that in the process of integration with other services, a user gets various configurations for testing and a real technical environment (a good example is using the third-party API).

Obviously, we should not concern testing and staging environments as meaningless things. We just can never be sure that if the tests were successfully executed in the testing environment, they will be successful to the same extent in the environment of other services.

And here appears the testing in production.

Real multi-level tasks and technical issues

Some groups of bugs can only be found after long monitoring of the system functionality on the basis of multitasking and a big load. Such situations are related to the system’s speed, software resistance, the stability of its functioning and possible memory leaks.

Problems during the deployment

As we know, the [highlight dark=”no”]deployment[/highlight] is a special process of deploying a new working version of the software inside the infrastructure of the production environment.

It’s logical to suppose that the best way to find bugs during the deployment is to directly perform testing during the deployment.

Short conclusion

We all understand that we can’t find all the bugs in production and even the most thorough testing in staging doesn’t save us from bugs in the production environment.

And if such defects are found by the clients, this may negatively influence the company’s reputation.

And therefore, [highlight dark=”no”]testing in production is a “must-have”[/highlight] for any respectable QA company.