Assuring Development Quality
3 Types of Quality Assurance Teams
What type of Quality Assurance team do you aspire to have?
As a consulting developer, I have had contact with many different Quality Assurance (QA) teams over the years. The water cooler talk amongst developers tends to hold as a matter of indisputable fact that QA teams are nothing but bothers and impediments to the smooth running of any project, hardly ever worth the time they require. As many such beliefs, it is partly based on genuine issues, and partly based on personal misconceptions.
Looking back, there are three archetypes of Quality Assurance teams that developers will gripe about…
QA Team Type #1
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”.
QA Team Type #2
The Long Detour
This type of QA is characterized by doing things by the book – the book in question being some 500 pages of seemingly irrelevant technical minutiae that applies to ideal cases which are never found in reality and will insist in long meetings where you must argue and defend your design choices in the face of their manual. Every meeting will require painful examining of code, but in the end their best advice is to ‘read the manual’ – maybe referring you to the correct page, if you are lucky, and to send the revised code to them for further analysis.
If you are now thinking that this QA is no more likely than the previous to prevent the infamous words of doom, you now know why developers prefer the previous one: the final state is the same, but at least we met the deadline.
Hey, but at least we made our deadline!
QA Team Type #3
Out of the Loop
This Quality Assurance 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.
No time to get specific!
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.
Success Story: The best quality assurance project experience so far.
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 a 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.
The key is finding the sweet spot between quality checking and a hands-off approach, and this is what every QA should aim for.
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 Quality Assurance 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.
If you have questions about quality assurance, or you’re seeking ad-hoc, temporary staffing or managed services, book on our calendar to have a chat!
Looking for more on Development?
Explore more insights and expertise at Smartbridge.com/development
There’s more to explore at Smartbridge.com!
Sign up to be notified when we publish articles, news, videos and more!
Other ways to
follow us:
