Outdated testing concepts #2

Reading Time: 5 minutes

Link to part one: Outdated testing concepts #1

This week’s outdated concept will be dedicated to the “quality guardian” or “The gatekeeper to our product’s success”.

Outdated concept # 2: The holy guardian of quality.

The first stereotype that was branded in my brain, in the first months I started working as a tester was: “QA is the person responsible for product’s quality” and “Your job is to prevent bugs from being released in production” or “Your job is to test the product so it meets the functional requirements / acceptance criteria” and so on.

I can now recall that I wasn’t really happy with the job title “tester”, to me it used to sound like someone who’s about to get shot out of a cannon or perform crash tests on a car or something. In other words “tester” seemed to me like a bit of an insult, while Quality assurance … wow that was shiny, at least to me, at that not too distant point in my past, it was rock star title to me, I was responsible for the quality of the product and I was told, I am the man to give my final verdict on shall it live or we will have to fix bugs until it’s done. Seemed like a pretty bad ass job to me … and it was all lies.

How are we responsible for quality?

Now, enough rainbows and unicorns so far, we are back in the present and we put on our “investigation hat” and analyze our part in product’s quality, and if it is really the principal role that was described to us, or just another outdated concept.

Let’s start at the pretty basic level:

• If the developers are writing crappy code, no unit tests, can we impact on that aspect of quality?
  No, of course we can discuss with them, brag, ask, threaten or whatever negotiation tactics we might use in order to make them do it, but we can’t actually force them to do it, therefore we are not responsible for that part of the quality, of the software product.
• If the requirements for the new features in our product are vague and ambiguous, impossible for us or the devs to decipher, do we have the power to change that?
  In fact we can, but it doesn’t guarantee anything. Why is that? We can protest against bad written requirements, we can ask for revisions and meetings in order to “sort things out” and make them clear and understandable for the whole team, but let’s face the reality, we are in the 21st century, we are mostly being involved in Agile and Scrum projects, because development teams like changes and they like ’em in big portions and at really high-speed. These poor requirements are probably not going to be the same only in a week, and who says they are the only source of knowledge for the product? What about the emails, or instant messages, other documentation like design blueprints, how about meetings, phone calls, conference calls, hangouts, 1 on 1 meetings or managers who tend to sit next to a developer and tell him “how it is supposed to work”… Do you still think you have reach on all that ? I strongly doubt it.
• If the management takes bad decisions for the vision of the product?
  No, after all we are there to help the product to succeed, but it’s not our job to manage it. Of course, we could be involved in management, but there’s certain management decisions that could not be argued. And this is the end of the belief that we have the right of “veto” over the release. And me personally, I am happy with that, I wouldn’t like to bear the responsibility for that decision on my own. This isn’t one man decision for a good reason – everyone makes mistakes and we don’t want to turn anyone, not just the tester, into a sacrificial lamb. It’s easier to have someone to blame and many companies might still do this, but it’s not the way to progress.
• Can we assure the quality of testing in general and/or the quality of our own job?
  This is a really tricky question, but I would say no. Do we really have a way to track the work progress and quality of the other testers, can we guarantee that the job they perform, even if documented, follows our understanding of high quality testing? And what’s even more critical – can we guarantee the quality of our own job? I personally wouldn’t, because it will be easy to delude yourself, and after all we as testers must always be suspicious and even our own skills should be tested and analyzed, through our own senses as well as from the feedback that other members of the development team, Only this way, we can be sure, that the job we perform adds value to the project, not only to our expertise, or as Keith Klain mentioned in a talk I linked in this post, this is a way to make sure “we are performing our testing holistically”.

And the list goes on and on… So, as we see, the responsibility about product quality isn’t a single person responsibility, it’s a team responsibility. Not in the terms of  “shared responsibility is no one’s responsibility”, but in the terms of, everyone adds value with his own unique skills to the product and bears the responsibility for the consequences of his mistakes.

So, from the picture that I drew so far it seems a bit worrying what we can do, isn’t it? Don’t worry …

“There has been an awakening…”

We are no longer happy being called QA and we realize that our real profession is testing. And by testing I don’t mean just “play with the product”, as we often get thought to believe by non-tester individuals, but the process of analytical, conscious experiment with the product in order to explore it, evaluate it(J.Bach) and provide expert opinion what are the possibilities for it to succeed or the risks that can lead it to failure.

So, how could we promote our job, from all what I said, doesn’t it seems that we all have no chance to change anything? No. Here’s a good list of actions we can perform to promote the real value of the testing profession:

• We have the most wonderful, interesting profession in the software business – the testing part, we can experiment with the product in order to expose its weak and strong sides.
• We can construct our testing as complete scientific experiment and develop not only our testing, but as well our scientific skills and the way we learn.
• We have the opportunity to put our hands on the product first, after the development team is done with it.
• We have the opportunity to mediate between the marketing, business, management and the technical teams within a software project and in this way learn way more information than any of these departments’ representatives alone.
• We can literally break stuff and no one is angry with us, sometimes we even get congratulated for breaking it. This is a joke of course, we all know “we didn’t break the software, it was already broken when it came”(Michael Bolton).

The list goes on and on. As you see, speaking of software testing as simply “someone being responsible for the products quality” is just naive and barely touches the surface of what software testing profession really is.

And last, but not least, I believe that the main way in which we can drive our profession to progress is:

I believe James Bach once mentioned these..

1. Learn the testing vocabulary and terminology.
2. Learn the testing methodology and techniques e.g. learn how to be experts in our craft and how to provide high quality service as testers.
3. Learn to explain our craft in a manner to promote our profession.

And I believe the last one is really important, we need to make ourself heard and seen, we need to learn to give a compelling story on what testing is and what is its true value.

That’s for this week, I hope it was interesting and useful, stay around for the next part. I will be happy to see your feedback, as always. Good luck 😉