In my first blog post I wrote about the purpose of quality. I drew a nice red thread from quality to everyday answers and asked you to come with me and dive deep into that journeyful subject. It took me some time to get on with it – there have been so many nice meetups and my hobbies interfered with writing.
But now I’d love to move on and talk about the tester behind the quality: the quality assurance (QA). So I’d like to introduce you to the people behind the curtain of that colourful abbreviation.
QA in person
We are a colourful folk, most nerdy (Yes, I do have a Nerf gun! – Okay, I admit, it is not only one.) and happy with what we are doing. We did not choose to become QA because we cannot code. We choose that path because we are good in what we are and what we do. We break things. To make them better. Okay, to let the devs make them better. Why? Because they are excellent in their profession and we are in ours.
Before becoming a QA I always thought about having just bad luck, because everything I touched broke (or literally shattered) into pieces of software. It happened oh so often; when I was surfing and something on a webpage or in a game or somewhere else did not work correctly. I never wondered about it, though. But then I got the opportunity to become a QA, and at first I was suspicious. Because I wanted to code! I wanted to be a full heartely developer! That was what I applied for in the first place. But after I dived in deep into the QA stuff, I found my tiny place where I was happy being a good code reader and a versatile tool to help find bugs. Or maybe the bugs were finding me. 😉
I always love to explain the job as QA for non-techies as „I have 8 hours a day where I can break stuff and even get paid for it. And it is fun!“. It is just half the truth. I do not tend to break stuff that often. And I am totally happy when there are no (findable) bugs. I am in a rage when I have a non-reproducible, randomly emerging bug, because those are the true buggers. And they devour lots of time – not only for me but for the dev’s as well!
There is a huge variety of how to be a good QA. There are people, who are totally in love with being just an explorative tester. They click and look if everything is going as it should. There are some people up for UX stuff or being good helpers in finding bugs when it comes to getting deep down the SQL road and head into the database jungle. Some are also digging into code and do code reviews, because that’s what they are good at and have fun with it. Others, who still want to be a bit on the dev track, do automated testing and support the devs by writing end-to-end tests. But most surely QA people are multi-headed and really enjoyable types of the IT minions. They can be little demons when they find out that the dev did not fix the broken code, but that is another matter.
Last, but not least: It is the team, that counts. Big time. I really mean it. I am in the lucky and happy position to be counted in a nice team and companionship with the most talented guys and gals from dev and product side (but I will fill that topic a bit later).
So, what exactly is QA? Quality assurance means mostly that there is a (business) process behind it. The QA person assures that the code written on dev side is on a certain quality level. We all know that we cannot prove that there are no bugs (and we cannot label a software „bugfree“ – that would be hilarious, seeing a product calling itself „bugfree“). We only can assure the stakeholder that there are no obvious bugs. That the software runs in its parameters and does not produce weird outcome (and even that can happen sometime when there are shadowed failures that neither QA nor dev thought of). The bugless-ness can only be checked at the productive stage, when real people run the software. Anything that comes up there might be an error the dev coded in and the QA did not find. And it could happen because of lacking in the acceptance critera or poorly explained processes beforehand.
We are here to help bringing less bugs live. We are not here to stand up for a bugfree software. And we need to change in this rapidly changing world of IT.
So – what is QA? It is a helpful tool to establish a better understanding of „what went wrong where“ and should be a guidance for the dev’s. In an ideal world, the QA should slip into the role of the „knot in the handkervief“ – helping the dev not to forget stuff or getting forgotten stuff back into mind. No-one is perfect and we all tend to forget things we learned about. Bur rejoice: QA is here to help! 🙂