How DevOps Is Making Testers Evolve
The DevOps movement focuses on bringing together development, testing, and operations so that feature teams have full accountability from code to deploy, with the dream of continuous delivery. But with this revolution, more and more companies are starting to abandon “traditional testers” and bring on software developers for testing.
Does this mean a tester will no longer be a role on the team? No—but it does mean testers have to evolve and ensure that quality is baked in.
The first part of the evolution is moving from being a good tester to a good team member. Get on the same page as your product owner and developer and ensure you are aligned on scenarios prior to coding and testing. (Utilizing behavior-driven development or acceptance testing-driven development is a great way to do this efficiently.)
Then get more technical by learning a programming language like Ruby or Java. Use that knowledge to leverage an open source testing toolset and integrate it into your continuous integration pipeline so you can work toward continuous testing.
The second part of the evolution is changing the way you automate. You need to be automating your tests in a way that aligns to the developer’s environment and makes it easy for a developer to run and debug your automation code.
Using an out-of-the-box automation tool or framework that dumbs down the automation process ultimately makes it difficult for the tester to keep up and creates a gap between the tester and developer. Those frameworks are just not as fast as writing your own Ruby or Java automation code.
The next part of the evolution is learning about service virtualization and other tools that help remove constraints. If you are going to achieve continuous testing, you need to ensure your tests are able to run without issue.
Many teams have to account for data requirements, test environments (third-party APIs, mobile devices, browsers, etc.), and external team dependencies. Coordinating all these variables takes a lot of work to run the suite once, let alone many times a day, every day. You need to leverage a service virtualization tool and other cloud-based tools to eliminate these constraints and componentize your tests. By isolating your tests by specific components, you can ensure high confidence without creating a need for a prolonged hardening or regression phase later on.
The last part of the evolution is rethinking how you design your tests. If all your tests go through the user interface, break them down among UI tests, service layer, etc. Remove tests that never fail and modify tests that fail often (flaky tests). Your testing suite needs to run throughout your pipeline, so not all your tests should run all the time or at the same time. Break them up into mini quality gates focusing on critical transactions and eliminate constraints so they can run again and again.
By evolving how you work and how you think about quality, you can stay relevant as a tester in this new world of DevOps.
