Out of the Loop
This QA type is in my experience the most common one. Their reviews will seem to be for a different project altogether, unrelated to either your understanding of it or your client’s requirements. They are never present in design meetings, and they seem to exist in a different place altogether – if not a different time.
They are less likely than the previous type to cause delays and sometimes they do deliver reports that help straighten the code, but more often than not the response to their requests is more in the quizzical puzzlement end of the scale, like someone discussing wallpaper designs for your latest windshield design. When talked to, they will freely admit to overwork and lack of hands. To deal with the innumerable request for their attention, they do only ‘overviews’ and ‘quick checks’, and never have the time to understand the specific projects, so their answers must be generic, rather than tailored.
A Change of Wind
Everyone knows what the QA department is for, but it is harder to understand how it should go about its business. I had personally grown used to dealing with QA departments in the same way I deal with poorly documented code or a known software bug: you accept it, factor it into the schedule, and do your best to deliver while working around it. Not something I am proud of but, talking to most developers, an unfortunately common situation.
In my last project, however, I was fortunate enough to discover the rarest of beasts: a QA department that actually prevented the infamous words of doom from happening, in an active, forthright and clear manner, not once or twice, but a good dozen times.
The Key of their –and my– Success
The project itself could’ve gone better, but there is no doubt in my mind that, without the QA team, it would’ve been catastrophic. The key, I believe, was finding the sweet spot between quality checking and hands-off approach, and this sweet spot is what every QA should aim for. It was never their job to check code. Instead, their job was to ensure that the system – the whole system, not its individual cogs – worked. They approached it as a black box, their QA diagrams centering in inputs, outputs and processes. By looking at the whole project as a massive black box, they were able to QA four different development environments, each with more developers than QA team had members, at the same time and without ever being the delaying step.
More importantly, as hinted above, they were always a central point of the project. Developers answered to them directly during steering meetings. A ticket system maintained visibility of actions and decisions, but at the end of the day, it was QA that drove the discussion of what worked and what didn’t, and all the developers were beholden to them. When QA is on the sidelines, a step in the process, QA themselves feel unconnected and thus even in their own mind become a rubber stamp. By placing them around developers, not after them, the development ran more smoothly.
And finally, for the most important characteristic: the QA team made the effort to speak to the developers and develop a rapport with all of us. This was possible because we were all in the same general office space, and being able to talk to one another blunted the edge of official emails and tickets – indeed, more often than not these followed the discussion, once we had all been able to address the problem and think a solution, rather than create a record of accusatory mistakes, which no-one ever likes.
Exporting this Success to Future Projects