Another trap coming up! Trap means we get to look at our less attractive attributes. This one deals with important stuff so let us look at that rhyme:
”When you find something scary while you explore You might be tempted to just shut the door But hiding it will never kill that ghost Bring to light what scares you most”
So, what does it mean?
It can be incredibly intimidating to be the bringer of bad news. Especially if you are new to a team/project, if you are a junior tester or just have some very strong voices pushing for speed. I mean, there is even a meme for it!
And yes, there is an art to knowing when/what/how to speak up and when it is better to wait. It is a skill grown and nurtured over the years and being good at assessing risk is one of the best skills you can have as a tester. BUT. It is a decision that should never be made out of fear! We have a professional obligation to speak up when we actually believe there is risk.
People will try to push you. They will try to get creative with results in order to make progress. They might ask you to lie. It is YOUR choice if you do.
I want to share Fiona Charles’ 10 commandments for ethical techies here: 1. Understand your overall professional obligations 2. Understand your specific legal and contractual obligations 3. Know your own ethical bottom line 4. Know whose interests you serve 5. Know how your software can do harm 6. Think critically about your whole situation 7. Be good at saying “NO” 8. Be good at telling more powerful people things they don’t want to hear 9. Know your escalation path 10. Know your tolerance for risk
My own ground rule is: If I choose not to raise something I found it must never be for my own winning or fear. I know that this comes from a position of privilege and I do not expect others to follow that rule but in the position I am – no job is worth breaking my moral compass for. Strive for an atmosphere and an environment where people feel safe enough to fail, show weakness/lack of knowledge or make bad choices. I strongly believe a team where people feel safe with each other is the nr 1 key to quality, speed and delivering value. (For support of this, see: Google research)
Briefly, I also want to mention my dislike for ”testers don’t own quality” and ”testers don’t decide, we inform”. While I, 100%, agree that quality is the whole team’s responsibility and that testing is not a gatekeeper I think people misuse it way too often. They throw their hands in the air and then smugly say ”I told you so” when shit hits the fan. That is not how I believe professionals should behave. If you truly believe there is an important risk – fight for it. Push back. Not to protect your own back, to protect the users and your teammates.
I already wrote an article about this as well as presented a talk on the topic. Both are linked in the reading suggestions below, along with a bunch of other reading material.
In my early years of testing we did a lot of waterfall development and testing. We planned for ever, wrote document after document and had metrics for everything. A common one was that we were not allowed to release with more than X known defects with Y severity. This was misused in so many ways I cannot even fit them all in here.
One creative way was that our business users raised the severity of bugs in order to get them fixed within a release, since the scope was decided by a bunch of management people. By raising severity they could bypass that. Drawback? Team always delivered less than originally planned and management was always upset with us.
Another way was of course to lower the severity of found bugs in order to allow for a release. Something I think a lot of seniors have experiences over the years. I can’t even understand why we even had those exit criteria, we never ever seemed to follow them. It always seemed to be gut feeling deciding if we released or not.
One last example I want to write about is an observation I made at one point. I was not part of any delivery team at the time but for some reason I visited a stand up of one of the teams. It was close to release day and one of the junior testers spoke up about feeling worried about the quality of the new features and feeling that not everything had been properly tested. In the beginning a few in the team asked a number of follow up questions but in the end – the product owner decided to release anyway. Of course, since I choose the example, the feature proved to be buggy and they had to revert the changes. I am extremely proud that that tester stood their ground for as long as they did and it was a good learning experience for both them, the team and the product owner. (Yes, I decided that the team was in charge of that decision and yes, I did my own quick risk assessment before I chose not to use my manager hat and overrule the decision.)
There are many examples out there, unfortunately not all of them are ok to write about. But I think you all got the message by now.
Stay true to your beliefs!
Quote of the day
“Testers don’t own quality or decide on go or no-go” should never be an excuse to turn a blind eye or not take responsibility when needed.”