Rise of the Full Stack QA

When working on an agile project one word comes to mind: Adaptability. Also know as the “wearer of many hats”. This principle holds true for development teams so why not quality teams? I use the term full stack qa to try and apply agile thinking to modern quality assurance. Full-stack has traditionally meant frontend, backend, and devops.

In modern QA practice, full stack means manual testing, test automation, and testops.

Manual testing

Every QA should have a fundamental understanding of how to test, including test design, approaches, and techniques. This includes our test automation engineers and infrastructure testers.

I have encountered plenty of automation engineers that will tell me that coding is all they do and anything beyond that belongs to the manual testers. This statement in particular will driver me bonkers. Testing resources and allocation need to remain fluid during sprint and test cycles to maximize testing coverage and capability.

Manual testing also provides valuable insight into the product that cannot be gained automating. One of the significant challenges in automation is test assertions and creating meaningful tests. How do I know a test is really failing? Is it a defect or test code? To answer this question, one can use manual testing. Determining exit criteria for manual scenarios based on customer feedback and insight can directly translate to assertions in our test code.

The list can go on. Negative testing is mostly a manual task, ad hoc testing to understand functional nuances in a product, and finding the mundane automatable tasks is done by manual testing methodology.

Automated testing

In the same way that automation engineers should understand manual testing, the reverse is true as well. Manual testers should have a fundamental understanding of automation design.

For example, if a project uses Behavior Driven Development, it is crucial to use the same principles across an entire project. In BDD requirements are written as specs and shared between each part of the team providing a common goal. If a manual tester ignores the approach being used by the test automation engineers, the specifications could be lost in translation.

Another important aspect is determining automation limits. When we write test scenarios as manual testers, we should consider the implications in automation. How difficult will this be to automate? What risks are involved to test coverage that automation cannot check for? By having this understanding we can provide the best test coverage possible to our customers and keep the quality bar high.

Test Ops

The last piece of the puzzle is testops. When I say testops I am referring to a couple of areas: Continuous integration, continuous deployment, and managing basic infrastructure related to these components. A critical role for a QA is to analyze test results from automation and triage these results. Having a fundamental understanding of the deployment pipeline can enable a QA to determine whether a failure is test code, infrastructure issues, or a true defect.

Another critical aspect is that when it comes to operations. Quality teams own the quality infrastructure. It is rare that the quality team will have a dedicated devops to handle their CI/CD. Concepts applying to automating test jobs such as parallelizing tests, test reruns, reuse of job templates can create significant gains in the testing process. Running tests in parallel alone can reduce a test suite from 30 minutes to 5 minutes.

Conclusion

By having these three traits, a QA can come into a team and create real change at all levels and maximize their impact. I encourage any QA professional to always keep growing by taking a look at these areas and seeing where they may be able to learn more.