How I see the QA mindset part 2— The Messenger
Nobody likes bad news.
Don’t be the messenger that gets shut down or ends up being disliked… or worse.
Advocate for the issues, but don’t identify with them.
Being passionate about your work is a commendable thing. A top tier QA must have this passion.
But — there’s a but — you need to calibrate it.
Story time.
It was the first time I worked close to the devs. I felt honored and humble. I just left the previous company, where I had around 15 colleagues, all QA’s. When we found issues we externalized our joy, especially if the issue was of high severity.
So, when I found issues (and there were lots of issues to be found on a 10 year old project with only 1 QA on it) I would get excited and let the joy out.
This did not sit well with my dev colleagues. They got to resent me over time and I did not understand why. They would put all the blame on me for everything that went wrong on the project.
I get them now, I probably would have done the same with the context the team had at that time: blaming each other was common, people were covering their backs and external pressure on a constant basis.
What I learned, or rather found out the hard way, is that some people can mistake your enthusiasm. They could think that you delight in their mistakes. Don’t jump up and down on the first few weeks when you encounter a bug, let your teammates get to know you first.
Your teammates could have low egos — you need to thread carefully. They could be stressed out on implementing the functionality that you are testing — don’t push anyone over the edge.
I was just being happy for myself, I was not thinking of the devs at all. I was thinking “I’m so happy that I am successful in what I’ve been hired to do”.
Mask the emotions with strong rational arguments and documentation.
Let’s go to the extreme. You find a deploy blocking bug, with a big deploy planned tomorrow. Or a bug that will need to restore the previous version on the Production environment. These are highly critical issues.
Don’t lose yourself. Keep being rational, keep your cool. Don’t say things like “I’ve found the mother of all bugs” or “this is the end”.
When a critical situation occurs, just report it to the correct boss. As a QA that is your only job when it comes to this, at this particular moment in time. Prioritizing and rallying the team is not part of your job description. That’s what the “M” people do (Manager, Master etc). If you know who can fix the issue, maybe even know the fix, maybe you can even implement the fix, do it — but, only after syncing with your manager.
Think of his position — he has his own managers who request information and status. How nice it would be to receive useful information and good news in a critical situation without requesting it.
If you keep cool this will happen:
- information will be clear, useful and to the point, there’s a possibility that the root of the issue could be known to someone only from your words
- no steps would have been skipped when investigating, so there is no risk of false alarms (you don’t want to become the next Boy Who Cried Wolf)
- in the future people will get to count on you and on your judgement, your words will have more weight
- no extra stress and pressure will be added, from your side at least, on the team or on the person who can fix the issue
- you will be ready to help with your energy at stable levels for a longer period of time
- at the end of the day you will be able to feel satisfaction for your effort better, and not only the exhaustion
If you don’t keep your cool the opposite of what I’ve written above will happen. You might even get a lollipop on your way out of the company.
Humans are the most important thing in a business. They can perform various and complex actions. Being able to keep using them in the future is very important.
A critical situation will pass, money could be lost during the crisis. But money don’t have feelings or memory. They are important but not critical. Money can come back to you if you know how to make them. With the right attitude one can come back even stronger from any failure.
The people are the ones making the money happen. Keep your colleagues happy, prioritize correctly.
Never make them feel stamped on or attacked. You might do it and fell right about it, but tomorrow it might be you the one with the mistake. I’m sure they will remember to return the favor. So, the blame game would start and a toxic team would be born.
I worked in a team where I heard the Product Owner saying about an issue in Production “This bug is on the team, not on any individual member”. But when one would consider all the details, it was obvious that it was the QA’s fault because the acceptance criteria was not met — and I might not say anything that will blow your mind — it is the QA’s job to make sure that the acceptance criteria are successfully met. But I liked the attitude — “we are not pointing fingers here, we are focusing on getting the job done”.
That QA improved his performance after that. He also remained with that team for a long time afterwards.
If someone makes mistakes from time to time, it is ok, it is a human thing to do. Respond in kind, with a positive human reaction. The other one might be feeling bad already — assure him he is still accepted and part of the team.
When the team faces hard times, try changing your mindset from
“It’s his/hers fault!”
to
“How can we fix this now? We’ll talk about why it occurred later”
When building applications, a mistake is a mistake. You should not hide that fact.
But you should never assume it was done badly on purpose.
Sometimes the root cause of the bugs can be found, or tracked to the team members and how they work together. Colleagues that are lacking in communication will, sooner or later, cause bugs and issues to occur.
Not all bugs come from the developers. I believe that a QA will double check everyone’s work, sooner or later, superficially or in depth.
Try optimizing the team you are working in to the best of your abilities.
Story time
I was working with a colleague from a different team. Let’s call him Bobo. He was assigned QA tasks on our team by his boss even though his talents were from a different field of activity. Not the ideal scenario for anyone involved.
My team needed any help we could get, but he would almost never deliver what he assigned himself to — the quantity of work was self assigned by Bobo.
The issue was that we had to cover the tasks Bobo was not doing. In one particular daily meeting he would even claim he did work on QA side. We knew that in fact he had done nothing.
This was unacceptable. It was draining our team’s morale.
So I got some emails going, where I would ask him how much he can contribute to the QA effort, with his boss in CC. He failed to deliver, for reasons only he knew since he was not very communicative towards us.
He was changed to a different position in a short time.
This was probably the best outcome for everyone involved.
I did not get emotionally involved even if the status quo made me upset and frustrated. I managed to use the emotions as fire and spearheaded my plan with rationality. The only acceptable way moving forward was to let the facts speak for themselves. In this case I was lucky enough to have a boss that would listen to the facts.
As a lesson, when delivering information, be ready to adapt everything — the information, the delivery, the content… to the listener(s).
Key takeaways:
- Advocate for the bugs you find, but don’t go down with the ship, follow the direction the “M” people are setting.
- Don’t fall into “The boy who called wolf” trap when a high severity issue is encountered. Take your time to think it through.
- Avoid at all cost hurting your colleagues feelings and playing the blame game.
- A QA should also try advocating for bugs in the team’s workflow. If something is not working well in the team — a QA should be the one to know this — act on it.
