Last week I published a blog post on work place culture. I look at some excuses a tester might make when confronted with a bug that went unnoticed. I then explain how these excuses might indicate an issue with the work culture, where fear and blame are encouraged, instead of the tester.
This post was inspired by another blog post by the thinking tester who discussed common excuses that a tester might make. This included ones I addressed in my own blog post and some others.
Here is the list:
I donāt know how the feature works Thereās no way to test the feature The developer coded it wrong The other tester on my team missed the bug There wasnāt enough time to test If I log the bug I found in Production, Iāll be asked why I didnāt find it sooner I donāt know how to code
What other excuses have you heard other testers make? How did you respond to these excuses? Are they an indication of the testers incompetence, negative workplace culture or something different?
I donāt know about testers, but the ābestā excuse I ever heard from devs was āItās not a bug, itās just something thatās failed far earlier than we expectedā.
Hereās one I used myself in a post-incident review meeting:
āWell, if the testing had been done on that pre-production environment weāve been asking to be fixed for the last eighteen months then the bug would have manifested itself straight away.ā
The workplace culture was well and truly brokenā¦
It all comes down to the fact they were thrown onto a new project in the last minute and believed everyone around them instead of looking for themselves. You live and learn I guess.
When I started in testing, I heard these phrases were stated by team members on other teams. Over the course of a handful of project, I heard these statements but usually in jest.
However, knowing that these statements may occur, I started establishing rapport with the project team (developers, testers, analysts). More recently, I collaborated with the lead developer to establish a team approach to quality; quality is a team sport. We had better unit tests and a lot fewer defects.
āWhy did you miss this bug?ā is itself indicative of bad culture.
Itās putting the responsibility of quality on a single person. Why didnāt the designer catch it? Why didnāt a developer catch it?
Itās not productive pointing fingers. Ask instead "what can we do to ensure that this type of issue doesnāt make it through again? What processes can we fix? Can we add some automated test coverage? Can we write some manual test cases?
I think project retrospectives are really important and theyāre extremely important for ongoing improvement!
Whether thatās down to incompetence is a matter of how much the lone tester is being asked - or told - to do and in what timescale.
And as for āItās so tiny I didnāt see the pointā - well, that may be down to incompetence, or it may just be the result of a negative workplace culture if small and apparently insignificant bugs have been rejected, ignored or belittled by devs in the past Obviously, such people have never had a small and apparently insignificant bug blow up in their faces.
These points could indicate something beyond what you said.
For example, āOur BA didnāt specify thatā is something Iāve heard frequently in my testing-life. In fact, Iāve heard it so often that part of what I consider testing is to think about what wasnāt specified which should have been specified. So someone using that excuse could also be bias (blind to things which werenāt specifically mentioned), inexperience (havenāt been burned by this scenario enough yet), or a simple mistake (oops, we all missed this point).
Where it can become ānegative workplace cultureā is after the mistake is made, nothing is done process-wise to rectify it. Like if only blame is set and fingers are pointed and itās āsomeone elses problemā.
Where it can become ātester incompetenceā is if the tester doesnāt communicate the cause of the issue and accept a portion of the responsibility.
Consequently, one of the things Iām guaranteed to test is any functionality where someone else on the team says āThereās no need to test this.ā Again, this comes from my own past experiences where thereās often a reason why someone would tell you that. In my experience, it can be that someone is masking a problem. There are valid reasons, such as "weāve tested this so often in the past, that thereās little risk in skipping this portion of testing, which is different than saying āno needā in that I will still test it, but it will be on the lower end of my testing priorities, and the absence of testing that feature will still end up in the testing report as well as the reason why it wasnāt tested.
You have a valid point, if the tester is being asked more than he can test and or in a tiny timescale. In this case I would recommend to hire more testers as well. But would it fall in testers incompetence if the workload was appropiate and the time as well?
As for the second one, definitely a negative workplace culture if you report bugs and no one fixes them. But if you work with a collaborative dev team, where does it fall?
I agree, context is definitely important in this case (āweāve tested this so often in the past, that thereās little risk in skipping this portion of testingā) . āNo needā just brings doubt to my test, I ask myself āIs there really no need? why?ā.
The hiring of extra testers is rarely in the control of the tester, so weāre looking at a negative workplace culture there. Otherwise, if the workload and the allotted time are appropriate, there may be other reasons. Incompetence may be one of them; but donāt put all personal failings down to incompetence. There may be issues in or out of the workplace that may affect performance.
Even if a dev team is collaborative, they may choose not to fix bugs that seem insignificant. The trouble then arises when some insignificant bug blows up in peopleās faces in unexpected ways. For example, I once raised a bug on an online teaching tool because of a (quite bad) typo which was in a large caption over the CEOās introduction. The CEO was not pleased. Sometimes quite small bugs can have reputational impacts that are out of all proportion to how they look to other people.
Itās clear now. Soā¦ donāt assume itās testerās incompetence if the rest of the process works. Again context is good. This makes me think of my boss, he used to say Hi to every single member of the team and ask how we were doing but with specific questions of our lives, I image that was him trying to see how weād perform that day.
