We have all heard the rhetoric that ‘Quality’ is everyones responsibility, but ‘Quality’ is not a metric that is easy to define. That is why we have QA. To my mind QA is one of the most maligned and under-rated roles in software development, but it is probably the most important of all of them.

It doesn’t matter how reliable or clever your product is if it ‘sucks’.

I have argued that Steve Jobs may have been a marvelous raconteur but that his real talent was quality assurance. His public appearance may have been full of rhetoric and bluff, but for the most part, the ‘reality distortion field’ experience converted millions of people to iPod and iPhone over a period of years, with a market that grew release after release and that is a hallmark of quality.

I don’t believe Mr. Jobs followed the evolution that I am about to outline at least not professionally, a successful start up will do that to you. In any case, that requires a mixture of luck and foresight which isn’t a pre-requisite for becoming a QA. But I do believe that, if nurtured correctly, you can grow your own QA.

Machina

Follows someone else’s test plan. Raises meaningless bugs that say that a test failed without any investigation in to the possible underlying causes.

This QA can and should be replaced with a script, but you don’t tell them that the script they are following has already been automated. You let them begin to get a feel for what a technology product really is and where they break. They have to feel the frustration of a broken build and deployment and learn to have a healthy skepticism of everything that comes out of a developer. Eventually they start to find bugs the automated software didn’t and are surprised when nobody is impressed.

Tester

Having been around the block a couple of times this QA is ready to work to the beat of their own test plan. They are starting to get a feel for where bugs hide. They start to make unreasonable demands from the development team like: “I want a stable build”, “Please add test X to the automation suite”.

Still young they consider their job to be finding bugs and reporting them. A product is ready when the bug queue is empty.

QA

Frustrated and confused as to why they are called ‘Quality Assurance’ yet they are embarrassed to show their friends and family the product they have been working on because of the lack of quality. Something has to change.

While still possessing little or no desire to be a coder, this QA is willing to admit that there is a database and that being able to query it may make their lives easier. They have learned advanced browser skills and enough about how CSS and HTML to not glaze over when the developer starts talking about the box model. They were listening when the product team were talking and really feel like they understand what the product needs to be. They were listening to the marketing team and really understand what it will take for the product to be a success. They were listening when the development team described their solution and asking how they were going to solve problem X if Y is true elsewhere in the system.

Deep inside the QA all the pieces start to fall in to place. They use all of this knowledge to help define what quality means for this product and apply it everywhere.

Product

Established as the font of all knowledge on the project this QA is given the power to reject a feature, not because it has ‘bugs’ but because it is not fit for purpose and will lower the quality of the solution.

They are the physical embodiment of taste on the project. The product team thinks they are on their team. Hell, they might even be the product manager, but we know the truth, they are QA.

They know that QA is what made them what they are today and empower the next generation to evolve to level 2 knowing that some will be lost to the dark side of development on the way, but that is ok. The seeds of quality have been planted and they will be better developers for it.

For reasons that baffle the current team they are involved in all hiring decisions to ensure that individuals share their passion for quality, or at least display the potential to learn it.

God

Impressed by the high margins and viral success caused by having the most tasteful and reliable product on the market you promote the QA to position where they can green light new products.

The years spent as a real QA makes them immune to the whines from the ‘technology’ group that solution X will save Y money because Z says it is cool. They don’t care if a server will deliver more pages per second, or if a new framework will allow the developer to finish features faster. They care if it means they can deliver ‘quality’ faster and that is where you make money.

The years spent in Product give them good instincts for what actually works in the market place and when to call it quits. Their best day is when they notice a ‘bug’ in a concept early and can the project before it costs the company any more money.

Years spent training developers and testers in the way of QA have given them good instincts for spotting ‘quality’ and they are not afraid to remove the bug, before it creates more problems. This gives them a reputation as a hard boss, but only from the people they fired.

They understand the value of having a holistic view of a product. It gives the impression of micro-managing, but that isn’t the point. They don’t want to do the job of their subordinates they are looking for the tell tale signs of a lack of quality. They may not know how to solve the problem, but they will be able to give repeatable steps that lead to the problem and trust that given these instructions the problem can be solved by their team.

You sit back and admire your handy work from the hospital you are building in Haiti with the spare time and money you made.

My experience is that most QA sit firmly in the ‘tester’ category and that most companies share the view that a QAs job is to find and record bugs until the queue is empty and that once a QA can be trusted to find the majority of bugs in software, their journey is complete.

Let’s not continue to make this mistake.