With the advancement of the software industry and more companies moving towards complete CI/CD, QAs are also evolving towards a blended role of operations and test engineers. These days we are building extremely complex software based on microservices, relying on interesting machine learning models and huge data points, therefore the traditional test and release process is a thing from the past and with this fast-paced development practice QAs need to come up with a process that fits for the purpose. Long gone are the days when QAs used to test all the code before it goes to prod or writes all the functional tests for the code developer is writing.

Continuous integration promotes continuous testing and it is not scalable if it depends on the QA team to add different levels of testing. Rather the QA can focus on paving the path for developers to write tests easily and also can provide all the necessary infrastructure support for running the tests as well as proper monitor and alert features. There starts the role of a TestOps who is not responsible for writing the test but responsible for providing everything that is necessary for the developers to write the test without thinking of the pipeline creation or managing the k8 deployment for the test or adding monitors in the test framework.

So why is it different from the traditional QA role or even the automation QA role? In the traditional world, we consider QA as the custodian of quality and they are the people to add tests, write frameworks but depend on devs, DevOps, or ops to manage the pipeline, create monitoring or maintain the infrastructure of the test framework. On the other hand, TestOps does it all except writing tests for features. The developer who is writing the code is the best person to write all the different levels of tests needed for this and s/he is the custodian of the quality of the code.

So what value TestOps is bringing? Nowadays we have teams working in different languages and almost detached from the development in other teams, often they reinvent the wheel by creating different frameworks for their purpose or there is no standard practice for making sure all the testing layers are achieved from the test pyramid. TestOps can come into the picture to solve this problem, coming from the testing background they have a strong understanding of different testing tools in the market and can build the right framework for the entire company, and can act as test consultants for the development teams. They can help the team adopt a new framework and make sure the teams are following the right level of testing practice. The test framework should be an easy plug-and-play tool that has a proper pipeline set, monitoring associated so that the development team can only add tests and they could get all the benefits out of the box. At Rokt, we built frameworks for E2E, Contract Test, Visual Regression Test, Load Test, Behavioral Test, and for all these, we have built the alert system, so if any test fails team gets notified. Also, we have built the monitoring dashboard on Datadog, thus the teams get an instant view of the entire system’s health. For different frameworks we have picked up a language-agnostic tool thus it could be adopted by different teams easily. Also, we have built mechanisms to run different tests with tags and collect data from it, so that we get an overview of how often these tests are running, which tests are failing, and the different test coverage across services.

Why would you want to adopt this? With bigger organizations and complex products, if you want your QA team to scale up, you will hit a bottleneck very fast. Rather I believe having the right people doing the right job is the key to success. The people who feel passionate about testing and quality could help build the perfect network of tests in the big organizations by paving the best path possible for the development team and can make the dream of perfect CI/CD a reality.

April 29 @ 14:30
14:30 — 15:20 (50′)

Erfana Sikder