Assuring Development Quality: 3 Types of QA Teams

Looking back, there are three archetypes of QA teams that developers will gripe about…

The Disappearing “QAct”

The department either doesn’t exist, or if it does, it is but a rubber stamp for any and all development. Most developers will privately admit to preferring this form of QA. No complaints, no denials, no extra steps when deploying.

Inevitably, programs will be put in production that don’t do what they are supposed to do, and eventually the meeting will happen where the developer will say the infamous words of doom: “the system is working as intended – it is doing what I thought it had to do”.

The Long Detour

Hey, but at least we made our deadline!

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

How can you go about applying this to your own project? Ensure that QA is not getting bogged down on the details. It is a very human tendency to have QA of every last line of code. But that requires a QA analyst for every developer, there is no two ways around that. Checking code, if anything, takes longer than writing it because you need to figure out both what it is meant to be doing and how it is doing it, where the developer already knows the second part. If the QA department is trying to double check all the code written, they will inevitably become overwhelmed – or you will need a veritable army of them.

QA should be the technical overseer of the development process. By requiring developers to provide with limited ‘black box’ prototypes QA can test from day one, you steer away from ‘Big Bang’ solutions and steer towards scrum style and similar agile development techniques. Quick turnaround when testing – or even better, incremental development based on the results of testing – will not just assure quality, it will help the developers’ own work by relieving some of the pressure from having to create test scenarios.

But most important of all, ensure that QA and developers can communicate with us developers. We are human, and as such we resent shadowy, unknown figures in emails criticizing our work – but are very willing to hear advice and get testing help from people we know and have spent time with. Even if you are a lowly developer, and do not have the ability to implement any of the other changes, you can still take the time to meet QA informally, get to know them, and thus save time and trouble in the long run. At the end of the day, that makes all the difference in the world.

For all the reasons described above, we at Smartbridge consistently make QA an essential component of our project execution. The QA function ensures that the deliverables are of a high quality and helps mitigate project risks for our clients as well as ourselves.

Keep Reading: Five Reasons to Involve Quality Assurance Early