Search
  • Mark Duffy

The Prerequisites For QA and Why I Hate Software Testers (even though I'm one myself)

What does QA mean to you? OR MORE IMPORTANTLY ... What does it mean to your boss!


I have never been able to figure the exact requirement of my role, no matter where I have been. As every where I go (even team to team) it is completely different. I know what I would like it to be! And this blog is about that... The world according to me!


I would be thinner for a start! But back to QA stuff.


Lets put some Givens down (our prerequisites)


. Given I Am A Product Expert

I know everything about this product, I can go from A to Z many, many different ways within the product. I know its ins and its outs.


. Given I Am Knowledgeable about the Customer

I know what the customer is going to do with our software, I know what others do, I know where the latest feature request comes from and I know where the product is going! I know WHY the customer will pay for this software, and I will know why they will go somewhere else!


.Given We Have Clear Requirements and Features

The developer knows what EXACTLY is required, including alternative journeys. The specification is simple to understand, even for QA .


It is only when you have these 3 prerequisites can you do everything that is expected of QA.


If I enter the number 5 in a cell, and another cell changes to blue... Is that right? If I do not know the software how do I know that is right? Most likely, because the developer has written test notes and told me, enter 5 cell blue! What if they hard coded that?


If I see a page full of information, sliders, tables, buttons and the customer, who will be using the page, will be in full PPE, including big heavy gloves. If I don't know the customer, and do not know they will be using PPE, then again, I have to take the developers word, they know, the specification makes it clear it would be used only on HD Screens with micro mouse movement!


If I can not follow what the the developer has produced, why they produced it, for whom did they produce it? Then how can I QA it?


Without these 3 prerequisites, you do not have QA! A developer does not need to know why they are being told to do something, they can sit there and just get it done. If the specification is good, they can just get on with it. And if that is what your QA is going, they are not QA, they are Software Testers.


Software testers role is ... does the software do what is being asked of it? Yes Or No! If you have software testers, and they are busy... Your developers are doing something very wrong. You have developers, creating software features, writing up the test, sending the tests to QA, and they are following the instructions, and failing the software? Did the developer not already do that? If not, why not?!!


What quality are these software testers bringing to the party? Does it work? Yes.. job done! Now a good software tester will then add things on, what if I do this, what if I do that, what if I go out of my way to break it, "what has this broken?" And I know many good software testers, but that is just testing the software. Knowing the customer will lead you to paths you would never think of, unless you knew what the customer MAY do.


QA look at the change, the UX, the reason for the change. Are able to understand the ramifications for other parts of the application, and if any customer will be pissed at this change. QA need the ability to point out the flaws, either from the the actual products look/feel, or on behalf of the customer.


I'm not saying QA is god.. (not out loud), but the above paragraph conversation should be held with the Product Manger, not the developer, they are just following specification, and if the PM say, its fine. It is fine and it goes in! Product Manger, Product Owner, are the gods!


The earlier this conversation happens, the better it is for everyone! As long as QA remember, they may not know the future, the PM and PO's will, so never take it personally when your cogent argument is denied. Just have it in your pocket come the Xmas party!


QA should be the best trainers in the company! They should have the ability to sit down with a class of professional people, who have never seen the application, and take them through the application, delivering learning outcomes specifically for that customer. They should have the ability to train the trainers, and know the industry they are training into.


Which brings the final question for this blog...


Is it better to take a product expert and make them QA, or take a QA and make them a product expert?


If you are a software house, you need product experts! But industry people normally cost lots of money. They also are very stuck in their ways, their way is the right way, and everyone else is wrong. And if you tell them they will be checking code, writing test plans, most product experts would run a mile, or worse !! WORK PART TIME!


I think it is easier to make a QA person from the development team, get them to understand the market, the industry. If your current product expert(s) can not train a novice to the who, what, why and where of your product, then are they really product experts?


QA do not need 20 years experience in the field they are testing, but they DO need to know what the customer does, why they do it. It also helps a great deal when the PM/PO comes out with a wacky idea, having an ex developer there holding them back, just a little!
















7 views

©2020 by Agile Testing.