Thinking about the QA/Developer relationship
At Infinity, we have a culture of testing. We believe in this so strongly that every Statement Of Work we create includes an introduction to our QA philosophy. Software is believed to be broken until it is proven to work.
Like many software companies, Infinity has a dedicated QA team that follows an incremental approach to testing software, including QA as a part of the development process from the beginning. As the developers make code changes, the testers inspect & validate. Sure, developers do their own testing, but, to make a broad generalization, developers test to confirm, while QA tests to interrogate. Testing software seems to be a contrary exercise to building software. Given that, could a developer benefit from seeing the other side?
What if we asked every team member to spend some time on the QA team? My colleague asked me this question not long ago, and my answer was an immediate "No." I imagined a bored developer navigating around a web application trying to break it. My thought was that a developer would rather spend their time building software than testing it.
Since I think we can benefit from studying the forces that oppose and complement us, I started to consider the idea more closely. A primary question in the mind of the developer is: "How can I build this?" A tester, on the other hand, ponders: "How can I break this?" While these questions may initially appear at cross-purposes, on closer examination, they are not. In fact, they are complementary, because the tester and the developer are both working towards a common purpose, to build a high quality product.
Think of everyone’s role in a software development team. Most of the roles are creative: architect, design, build. However, when testing, the tester sets out with the intention of breaking. To be a tester is to be skeptic. The tester must be doubtful and devious, think of scenarios that deviate from the expected path. Consequently, a tester’s role is unique and their relationship to the product they test can be adversarial.
This is where QA can go beyond science and become art. The best QA people can report issues to developers without appearing as adversaries. This does not come through the use of fancy words or tricks, but through having built strong relationships with the developers. It comes from trust.
Aligning the forces
Imagine if policemen, as part of their ongoing training, were asked to take part in an exercise where they became thieves for a length of time. They would steal items of value from different places and, just like thieves, try to evade the law. Wouldn't this exercise help them think like thieves, be devious? Wouldn't they, as a result, be better at catching thieves?
Of course, the tester is not like a thief, and the developer is not like a police officer, but the way they each view software is radically different. I wouldn’t make it a rule, but I say, yes, let's have developers engage in testing software. There is something to be gained. They could incorporate the tester’s “How can I break this?” or at least “How will QA try to break this?” in their mindset.
The most natural place to try something like this would be with new hires. We could establish an onboarding process that has new developers spend time in the QA team. This will allow the new hire to see our code, processes, and workflows from different angles and expand their perspective. It will also give developers a solid relationship with the QA team, a foundation for trust, giving them the best shot at working well together going forward.
There is an old saying that you don’t know a man until you’ve walked a mile in his shoes. That’s true in life, and it’s true in teams. The more we can get our people to see things from another perspective, be that the client, the QA team, the end user, whatever, the better software we’ll be able to create.