One common refrain I’ve seen in almost every team I’ve been a part of is that there’s a divide between QA and developers. It manifests itself in something like this:
We need a process where code isn’t just ‘thrown over the wall’.
We can’t spend time fixing that and trying to make our deadline.
We have QA who will find those issues. Let’s focus on adding features.
It’s harder for us to test this if you don’t document how it works.
Why can’t we just build a test automation framework? That’s solve our problem.
Why can’t we just have developers manually run through the test cases to help QA?
Testing is everyone’s responsibility.
We don’t have time to test now, we’ll take on that risk for delivery, we’ll test after the release is done.
If we don’t spend time focusing on quality, our stakeholders won’t trust us to deliver quality software.
And the list goes on. This tension is really common. I’ve never seen a team completely free of this tension, and I can’t help but think it’s a by-product of how we develop software.
We develop software to ‘get features out’ without really a care towards planning each part and how it relates to the whole methodically. And on the other hand, when we do plan methodically, we go too slowly and end up abandoning it halfway through the project.
QA, on the other hand, has a sole mandate: Make sure any problems a user encounters are found before the user encounters them.
Now, imagine your team changes how it develops software, without sacrificing velocity. Imagine a team where:
Developers develop software against a specification of tests; where edge cases can be added to those tests trivially.
Developers document how their API works through those tests (this is a good first pass, but is not sufficient on its own)
Developers respond to what QA finds by adding new test cases that cover the bug.
QA is able to focus solely on customer facing problems and system-wide testing, and not logic or environmental errors
QA and Developers are able to communicate over a common way of setting up tests: Arranging the data to be tested, acting out that test, and asserting what’s true; and those tests are in source control near the code they affect.
Developers and QA feel like they’re a part of the same team because testing truly is everyone’s responsibility. Developers use TDD to ensure their designs are extensible, their logic is organized, and their expectations for the code are spelled out. QA can rely on this test output to understand what parts of the system developer’s have tested, and see the holes for themselves, with confidence that someone has run tests against this code before.
The world I describe is not a pipe dream. If your team embraces Test Driven Development, you’re able to cultivate the conditions that make this world possible.
I offer team immersion training for TDD for .NET teams; this helps developers and QA alike see the world from each other’s perspectives and to help close the divide between developers and QA.