Say you want to convince people in your company to rebuild the pipeline in a TestOps way. We've already written a detailed guide on how to implement TestOps, but what about persuading everyone in the first place? Whom do you turn to, what kind of arguments could you present and what kind of 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 of them below. But first, it's important to understand when to start convincing them.
If it works, why fix it?
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, and a company is likely to take the risk when problems start popping up.
Add to this the fact that TestOps really shines when there is a crisis at hand. 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 is a basic premise 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 terms of 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 if the moment is ripe? To begin with, take control of the pipeline. Convince people who work with the technology directly.
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 responsibility of the team, 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 be teaching developers, reviewing their tests, communicating with admins on infrastructure, and handling 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 integrated properly into the pipeline, handling flaky tests is pure hell. In a supposedly automated process, you'll be spending hours sifting through test failures manually, 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 sort of testing anyway, and many are open to the idea of taking on more. But writing manual tests or using Selenium is too far outside the scope of a developer's toolbox, and this might be a major 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 are going to 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 the new version on new servers. This can be avoided if QA has access to the servers and can deal with the issue on their own.
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 here is - will it be worth the invested time? You can tackle this question from the user and money angle. If the development cycle is shorter, it means features get to users quicker, and it becomes much easier to react to market demand. Quicker resolution of bugs and issues as well as higher quality of support 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 that you start with figuring out the biggest problems your team is facing. Maybe your team members are overworked and everyone has the weight of the world on their shoulders because without them everything breaks down. Or maybe the users are unhappy because stuff is broken and fixing it takes forever. Then, convince the gals and guys in the trenches. Having their support, go to the product owners and talk about costs and benefits.
