While there are no “silver bullets” in software development, there are organizations that get the lion’s share of media coverage for their achievements around software delivery speed. When the likes of Google, Facebook, Amazon, Spotify, and Netflix share how they consistently deliver innovative, high-quality software, people listen. And, when it’s revealed that tech giants of that size share a common philosophy around any stage(s) of the software delivery lifecycle, organizations who are eager to reach those same metrics will ask, “Could that work here?”
For example, Google and Facebook share a very similar approach to software quality. With billions of users between them, these two massive enterprises must be doing something right. What is it?
According to Evan Priestly, an ex-Facebook engineer:
At least as of April 2011, Facebook had no employees who were dedicated to QA or otherwise performed QA as their primary job responsibility. There were some employees who do some vaguely QA-like things, but this was a small part of their job.
Wait, nobody is “dedicated to QA” at Facebook? Maybe this isn’t the similarity I was thinking of. Surely, Google has software testers. Here we go, it looks like James Whittaker will clear things up for me over at the Google Testing Blog:
Product teams can’t place too big a bet on (testers) and must keep their quality house in order. Yes, that’s right: at Google it’s the product teams that own quality, not testers. Every developer is expected to do their own testing. The job of the tester is to make sure they have the automation infrastructure and enabling processes that support this self reliance. Testers enable developers to test.
What does Facebook have to gain from having “no employees who are dedicated to QA,” and, why wouldn’t testers actually do testing at Google? Says Priestly:
By paying less attention to quality, Facebook has been able to focus on other things, like making the company a fun place to work at [sic] how to that can attract and retain talented engineers.
After giving myself a minute to lay down and try to comprehend what I’d just read, I recalled that Tricentis founder, Wolfgang Platz, recently wrote about this same topic—but from a differing viewpoint—for Infoworld. In “Agile developers test, but aren’t testers,” Platz points out that “agile adoption has blurred the historical distinction between testers and developers, and that’s a good thing.” Platz defends the murkiness of these roles by saying that successful agile development will result in developers testing more often than in the past. However, ”If your testing is primarily comprised of bottom-up tests designed by engineers, you’re likely to overlook critical issues,” and you’ll ultimately “threaten to undermine the goals of agile.”
The wide variety of views on how much testing should developers perform, and, likewise, how much programming knowledge should be required of testers, has resulted in an oftentimes controversial debate in the tech industry. A simple Google search of “Should developers test?” and “Should testers learn to code” produces over 10 million search results going back nearly ten years.
In an effort to give all parties the opportunity to share their thoughts on this matter, Tricentis is hosting what we’re calling “The Next Great Debate in Software Development.” Accenture Managing Director, Jeff Wilkinson, Electric Cloud CTO, Anders Wallgren, and Tricentis founder, Wolfgang Platz will provide their own unique takes on who should ultimately be responsible for software quality, and how agile and DevOps have shifted expectations and skill sets. We hope to see you there.