Despite all your planning, the release made it to market with some significant bugs, and your company has had to run damage control. Now you’re getting questions about what went wrong, and before you know it, the blame game is in full force, with your developers and testers pointing fingers at one another.
So what happened? Whose fault was it really? And what can you do better next time? The truth of the matter is, at a time when the stakes for software development are higher than ever (and only continuing to rise), the blame game simply isn’t going to cut it. And if you’re operating in a true DevOps environment, the finger-pointing should never even happen in the first place.
How we got here: The origins of the blame game
Before we dive into the solution to the blame game problem, it’s important to understand its origins.
Not too long ago, most teams operated in a waterfall environment that segregated developers and testers. Within this setup, each group worked in distinct silos, drawing firm lines in the sand when it came to who was responsible for what.
It’s from this waterfall environment in which development and testing operated as almost completely separate entities that the blame game was born.
Where we’re going: A closely aligned future
Today, waterfall is no longer the methodology of choice for most organizations.
That honor now falls to DevOps, which focuses on aligning software development and delivery to create a continuous delivery model. More than three-quarters of organizations have adopted DevOps, with 30 percent reporting company-wide adoption, according to RightScale’s 2017 State of the Cloud survey. Two key tenets of DevOps include close collaboration among developers, testers and operational teams and an emphasis on quality as everyone’s responsibility.
Unlike in the siloed waterfall environment in which teams are organized around functional disciplines, DevOps calls for each discipline to work together to bring new releases to market more efficiently. An ideal DevOps world consists of end-to-end, cross-functional teams, whose members all share certain responsibilities around testing.
Where we are today: Moving past the blame game
Of course, we don’t live in an ideal world, and DevOps is still a relatively new methodology for software development. Adoption doesn’t happen overnight, and most organizations that have embraced DevOps are still far from maturity, with a mix of modern and legacy systems and processes.
Whether or not your organization has fully committed to DevOps, there are certain key principles that you need to embrace at the outset in order to make it work. Chief on that list is tight alignment between developers and testers with quality at the center of everything they do.
At this point, we all like to say we’re operating in a DevOps environment, but when the blame game ensues, it’s a sign that your team may not be as aligned as you thought. That’s because DevOps makes quality everyone’s responsibility, framing it as a team endeavor that’s not isolated to any one group. With that in mind, in a DevOps environment, everyone should feel they shoulder part of the blame for releasing something of subpar quality. In fact, the whole point of DevOps is to have the entire team aligned around a shared objective of getting the highest quality product out the door as quickly as possible, not parsing out responsibility within silos. As a result, in a true DevOps environment, you win and lose as a team, and that means no pointing fingers.
Doing better next time: Top tips to improve alignment between developers and testers
If you recognize that your team isn’t as aligned on shared goals and responsibilities as you thought, what can you do to remedy that? Start with these five tips:
1. Focus on alignment
Developers and testers need to improve their alignment immediately, as the longer you wait, the harder it will become to bridge that gap. The best way to do this is to create project-specific teams that include both developers and testers, so they can get used to working alongside one another.
These project-specific teams should be created before the software development process begins in order to ensure proper collaboration from start to finish. Establishing cross-functional teams for which successful delivery to end-users is a shared responsibility helps each individual understand how they contribute to the success of the project and the business as a whole.
2. Bring quality assurance measures upstream in your processes
Second, it’s critical to make sure that quality assurance is happening as early on in your processes as possible.
These quality assurance measures should include adding efforts like exploratory and session-based testing throughout the pipeline to validate progress and provide feedback before moving into production.
By bringing these quality assurance measures forward in the project timeline, your team is not only likely to catch key problems earlier on (thereby allowing for more time to resolve those problems), but you also help create a more natural alignment between developers and testers. After all, if quality assurance doesn’t happen at every step of the way, then your testers likely aren’t involved as early as they should be, and you are missing the opportunity to identify and address errors as they arise.
3. Emphasize communication and transparency
Next, you need to ensure that developers and testers are communicating with one another throughout the entire process and maintaining transparency about everything they’re doing. Once again, this communication and transparency should stem naturally from tighter alignment between the two groups.
As obvious as asking your developers and testers to communicate and be transparent with one another might seem, it’s important to stress that no task or finding — no matter how trivial it may appear — should go unshared, as different perspectives may catch something that would have gone unnoticed otherwise.
4. Prioritize documentation
As you take steps to improve communication and transparency, documentation will inevitably come up. That’s because proper documentation can help achieve this transparency. It can also help hold the entire team accountable for their work and for tracking progress throughout a fast-moving release.
5. Walk a mile in your counterpart’s shoes
Finally, and perhaps most importantly, it’s essential that developers and testers speak each other’s languages.
When true alignment occurs, the lines between development and testing will be blurred, and developers may even take on some efforts traditionally handled by testers and vice versa. In this environment, both sides need to at the very least know how to talk the talk of the other, if not walk the walk (consider it more of a phase two to have your developers learn some light testing skills and your testers learn some light development skills).
Leaving the blame game behind once and for all
At the end of the day, even the most respected teams have their poor releases. In these cases, what matters most is how you pick up the pieces, and it’s hard to do that well when your developers and testers are busy pointing fingers at each other.
If your team is still playing the poor release blame game, it’s time to take a step back and do an honest assessment of where you stand in terms of DevOps, because it’s likely that your environment isn’t as mature as you thought. Even if that is the case, it’s not too late to right the ship by following the best practices outlined above for improving alignment between developers and testers.
And if you can do that, you’ll be well on your way to a more mature DevOps environment — one that can not only more quickly resolve errors in production, but one that also experiences those errors significantly less often.