QAshido – The path of the tester. Virtue # 2 – Quality advocacy and negotiation skills.

Reading Time: 6 minutes

Link to QAshido – The path of the tester. Virtue # 1 – Technical skills.

Why are negotiation skills important?

I don’t think it makes sense to put importance to the 7 groups of skills I mentioned, or as I called them virtues, they are all valuable, but I think being a good negotiator is one of the skills a good QA can not miss. Because soft skills and in specific negotiation skills are the thing that help us reach our goals and influence the projects we work at. It is from vital importance for a tester to have that skill set in order to be not just the person that tests the software but the person responsible for delivering a quality product.

What’s a quality software product?

That’s a good question, and it’s not quite on our topic, but later you will see why I decided to cover it. So, if we open one of these thick textbooks that claim to turn you into a professional if you pay $300 for the course and buy the book etc., the explanation would be – this is a product that is not bug free, we all know this is impossible, but a product stable enough so it meets users expectations. But this is only one side of it. A quality product is so much more, a quality product is one that comes on the date it was announced to be released, and having all these features announced to be included. And probably you’ve seen cases where releases were cancelled or features were cut off because the team failed to deliver the product as promised. Having a stable product depends a lot on having a team working as one unit, where everyone has their responsibilities and knows what to do, instead of wondering around and expecting somebody else to do their job,  or excuse with unexpected circumstances.

Believe it or not, a QA’s job is vital for any of the points mentioned above. It’s our job and responsibility to take care for all of these, not by doing it, but at least by having these in mind, and anytime we see anything go wrong, just as in testing, we report it, to the person responsible. In other words, it’s our job to ring the alarm, when things go wrong.

 The balance.

Just like Themis on the picture, it’s our task to maintain the delicate balance between the technical and the business part of the software team. Normally in a software team the technical part of the team represented by the developers would like to have some of the tasks done by the easiest way possible for them, and this is quite normal, they might have million of other tasks or that specific one might be boring or whatever so it’s our responsibility to look not just for bugs, but whether or not the features implemented fulfil our client’s expectations, or sometime even if the feature, module or application is usable at all. By this I mean it’s not just the functional part we have to take care of, test and done, it’s the non-functional part, too. And I know when it comes to usability, there’s UX designers dealing with it on design phase, but long time ago when there was no such profession, the QAs were doing this, and good testers even today, are doing it very well, even without asking whether or not it’s their job.

On the other hand we have the business people, project managers and stake holders, who have the uneasy task to release a product in a very dynamic area such as the IT, where things change at the blink of an eye. So they try to push as hard as they can, so the product is out as soon as possible and if possible add some more features, or some tweaks at the last moment. It is again our task again to ring the alarm at the point we believe making a change or adding a feature might cost the products quality. I don’t say we will have the right to make that call, but for our own sake, and our team’s it is good if we won the possibility to speak our mind freely and being heard. And this here, requires very good negotiation skills.

The conflict.

Like it or not it comes a moment where conflict is inevitable – a person will get angry because you found a bug, or another QA will get angry for testing the same path or feature over and over again. And here is where the skill set of a good negotiator plays it’s part.

It is not an easy task reporting a bug sometimes. We all think of it like just logging it into the defect management system and it’s not my concern anymore. But it is in fact. Sometimes developers will argue, will blame you for having old build or having the wrong setup on your machine, or testing environment, and it’s not necessary to be in a bad manner they might misguide you in a most polite way, without even knowing, so it’s your job to stay focused and doubt everything before you rush to reinstall the application or your testing environment. It will save you and your colleagues tons of time if you do this, and believe me, even if they got mad when you reported that bug, they will appreciate it when you spent them this additional bother.

The hater.

Dealing with moody person or a person that believes that this is not a bug in the software, but “it’s you testing it wrong”, “this is not a valid case, no one would do that” was always a problem. It’s always hard to reason with people that have the “I am right, you’re wrong. Period.” attitude. So, negotiation skills and standing for your position are valuable skills here, and most of all – patience. You have to be patient enough to sit with the guy and talk to him, not scream, not conflict, just a talk. You will have to develop the skill to explain your steps, like looking yourself from side, in order to give the other person the perspective to your work, and all the “why”s and “how”s he needs to know, in order to understand why is this an issue or why you consider that control unusable or whatever. And one more thing, always meet people in person, unless you are outsourcing. You will find this much more productive, much more efficient, than messaging or video talks. It’s way easier, especially when it comes to delicate topics like somebody getting angry when receiving a bug reported.

And it’s a good thing to look at “the hater” not as an unpleasant human being we have to just get used to, it might be anything that’s troubling that guy, so try to be friendly, don’t argue, everyone has his bad day at work, and tomorrow you might be “the hater”. It’s important to figure out that in our job it’s important just like in Stephen Kings’ “Green mile” to “Talk, not yell”, because there’s plenty of tension in our day to day tasks, and we can only make it worse if we argue and start conflicts.

The final verdict.

And last but not least, good quality advocacy skills are important because after all, and this is like huge percent of the cases, it is our last call to judge whether or not that product or feature or module is stable enough to go live. And to do this we have to be extremely good at giving the explanation why. The good part of our job is, anything we say, we have to show or demonstrate, which makes it really easy for us, if we can’t defend our position, why the product should or shouldn’t be released, we are simply wrong. So a good way to test it.

And it’s not always the case, of course, sometimes we need to release and we need to do it with defects. What we do then is we try to minimize the defects to only leave the “cosmetic” ones when we release. In order to provide confidence to our clients in the quality of the product, you will have to be the person that will explain in the most user friendly manner why is this defect of low importance or why is that one so urgent to fix.

So I guess that pretty much sums it up, of course as always there is much more to be said on the topic, and I am not even close to the belief I wrote anything on it, I don’t even try to, I will leave this opportunity for my book, if I decide to write one someday. 😀 Until then, if you liked the article or hated it, or found a typo, or just want to share your opinion on the topic, please don’t hesitate to write a comment and share it. Thanks 😉