There you are, all convinced about the advantages of TestOps and now trying to persuade others in your company. We've already written a detailed guide on implementing TestOps, but it supposes everyone is already on board with the new approach. How do you persuade people in the first place? Whom do you turn to, what kind of arguments could you present, and what questions can you expect?
Remember the Three Amigos of Agile - the developer, tester, and product owner? To whom we should, of course, add the admin - they are every bit as important! Well, for those amigos to cooperate, we'll have to convince each one in turn that TestOps is the way forward, and we'll talk about each one below.
But first, we need to understand when to start convincing them.
If it works, why fix it?
Why indeed? We've heard this argument time and time again when talking to people about the benefits of TestOps over the classic team structure. Unfortunately, there really isn't much to say in this situation. Any fundamental innovation is a risk; a company is likely to take the risk only when problems start popping up.
Add to this the fact that TestOps shines when there is a crisis. If the developer, the admin, and the tester are locked into their respective specializations (as they are in a classic team), then a breakdown of the pipeline will be outside each of their individual areas of expertise. Problem-solving will require them to work together, and if they want to avoid problems altogether, they will need to cooperate constantly and have established lines of communication. All of which are basic premises of TestOps.
So this is what you should look for - what problems can TestOps solve in your company? Here, a lot will depend on how far your company has progressed in automation - again, take a look at the stages of automation and team integration that we've lined out; they're gonna help here a lot.
So, who do you turn to when the moment is ripe? We should start convincing people who work with the technology directly - so that we can take control of the pipeline.
The pipeline: Testers
With TestOps, the role of QA changes dramatically, as does the content of their work. Traditionally, they're the keepers of the QA black box; they write the tests and get the blame for them. In a TestOps setup, writing tests is the team's responsibility, and QA oversees that process while providing the right tools and productivity enhancement.
In addition, automation takes over most of the work that testers used to do, freeing them up for other tasks. Now, they will teach developers, review their tests, communicate with admins on infrastructure, and handle the more complicated test cases. In other words, the work becomes much less routine.
For instance, if the execution of your automated test suite is not properly integrated into the pipeline, handling flaky tests is pure hell. In a supposedly automated process, you'll spend hours manually sifting through test failures, figuring out what went wrong in each case. All of this can be avoided with TestOps.
The pipeline: Developers
Of course, you've also got to bring on board the developers. Talk to them about the feedback loop with QA. It's always easier to fix a feature while it's still fresh in your head and you're in the zone, right?
Besides this, developers usually do some testing anyway, and many are open to taking on more. However, writing manual tests or using Selenium is too far outside the scope of a developer's toolbox, and this might be a significant obstacle. That obstacle can be overcome by
- writing tests in the language that developers already use to write code and
- keeping the tests in the same repository. We've already written about Miro's experience with that approach.
The pipeline: Admins
Admins might have reservations about TestOps. After all, it requires giving access and partial control over infrastructure to people in other departments. However, a separation of sorts can be achieved here. The Ops people care more about low-level stuff, hardware, and script-level maintenance, whereas QA will need access to the configuration of their testing environment.
The main point here is that if testers take over managing the testing infrastructure, it will reduce the workload on admins when extreme situations arise. A fix for something found at staging might require the admins to spend the weekend rolling out a new version on new servers. This can be avoided if QA can access the servers and deal with the issue independently.
Just as the QA people start supporting and mentoring developers with writing tests, the admins take on the role of backing up testers.
Managers and Product Owners
Once you've got the tech people on your side, it is time to take the talk to the higher-ups. Implementing the approach might take months, so the main issue is whether it will be worth the time invested.
You can tackle this question from the user and money angle. If the development cycle is shorter, features get to users quicker, making it much easier to react to market demand. Quicker resolution of bugs and issues and higher support quality mean more satisfied users.
Another important argument is that automated processes, while dumb, are quick and reliable. This means there is less room for error, and it becomes easier to keep to the deadlines.
The breakdown of institutional silos achieves the same thing, but in a different way - one person's failure becomes less of an issue if the necessary knowledge is spread among the team. In other words, the bus factor grows rapidly.
Summary
In short, we suggest you start by figuring out the biggest problems your team faces. Maybe your team members are overworked, and everyone has the weight of the world on their shoulders because everything breaks down without them. Or perhaps the users are unhappy because stuff is broken, and fixing it takes forever.
Once you're clear on the main problems, convince the gals and guys in the trenches. With their support, go to the product owners and discuss costs and benefits.
