In this two part blog post I will look at the process of selling Quality Assurance (QA) to the project stakeholders and in particular the client. In the second part I’ll sell the QA process, but for now we will begin by selling the QA Professional for all they are worth...
Round 1 - Selling the QA Professional
Throughout the career of many QA professionals one phrase has persistently haunted them:
“Testing? Anyone can do testing! Why don’t we just get ‘X’ to do it?”
‘X’ invariably being anyone from a ‘graduate’ (course taken is naturally deemed unimportant), the receptionist, someone who wants to break into Project Management/ Design/ UX/ “Digital” (notice it’s never QA) or pretty much anyone within the company who finds themselves with a few hours of downtime one afternoon. After all, as I’m enthusiastically informed about my chosen profession, testing only involves “clicking around a website a bit, RIGHT?” Err... wrong!
While nowadays such comments are mainly said in jest, it does highlight that sometimes we still need to dispel this basic misconception, that ‘anyone can do QA’, when selling QA to project stakeholders.
So let’s look at 6 reasons why, when it comes to QA, its best left to the professionals.
1) Experience
It sounds unremarkable but the experience of a QA is invaluable. A good QA, through years of finding defects, understanding elements such as mobile/ web browser limitations, web standards etc can often spot a potential problem before coding has even begun. Not only will this provide valuable time savings but, through experience, the QA will know how to communicate this issue clearly and will likely know the solution used the last time it occurred so can even help with the fix.
2) Qualifications
Like most professions, qualifications can help display your proficiency within a given discipline. QA/Testing is no different and a range of qualifications are available through bodies such as the Chartered Institute for IT, the most common being the ISEB/ISTQB Foundation certificate. These qualifications ensure that QA Professionals use industry best practice throughout their work, which will greatly benefit any project.
3) Finding the cause
While “clicking around a website” may yield a few bugs, the chances are a professional QA will be examining a web pages HTML mark-up, querying a database or editing content in the Content Management System to generate their bugs. While anyone can “click around a website” they are only scratching the surface, a good QA goes further, finding the root cause of a defect ensuring that the developer does not waste time trying not to replicate the issue and can get on with fixing it.
4) The Tester’s Mindset™
Often after finding a defect I’m told “How did you spot that?”, and while I usually say modestly “Oh, you know, just did” (while internally suppressing the urge to say “because I’m amazing!”), more often than not it comes down to having the tester mindset. Good testing requires a great deal of patience, exceptional eye for detail, hard work and an ability to clearly break down functionality within their mind. If you don’t have these skills, then you’re unlikely to find half the defects a professional QA can.
5) The right tools for the job
A good QA will use the right testing tools for the job. Selecting the right tool could mean that rather than ‘anyone’ just testing a function manually 100 times it can be tested fully just once. Or for example often we will try to add value by automating the testing ensuring that time and money will be saved at later stages in the project.
6) Objectivity
The professional QA provides a level of objectivity that will result in more defects being found. A developer may be too ‘close’ to a project to take a step back and see a potential issue (i.e. can’t see the wood for the trees), while the Project Manager may not see bugs but rather potential costs to the project. The professional QA is not burdened with any of these issues, and utilises signed off documentation to ensure that everything is being built in the way the client has agreed to, and not in the cheapest, or simplest to code way.
So, do you still want the work experience lad to do your QA?