…can often be perceived as much as an art as a science but there are certain patterns and phrases that reproduce from project to project: -
Image thanks to Office365.
- This bug doesn’t reproduce in my Development Environment. The flip side of this is, “It’s a known bug”: when either of these are uttered you can pretty much assume a unicorn just died… horribly.
- Automated testing will solve all our testing issues and find all the bugs.
- We have a zero tolerance attitude to bugs.
- Unit testing? We don’t need that here, it only slows things down.
- Who is Manuel Testing?
- Can you please stop talking to the developers about bugs? It stops them working.
- We invented Agile but we have a unique blend of it with Waterfall and bits of CMMI.
- No, no, no! I’m telling you. It’s a feature not a bug.
- Why do you need to understand how the customer will use the software? You’re Testing not Product or Sales.
- We maintain a proprietary Bug Tracking System we built on top of Excel.
But my all time favorite for real world testing albeit not software testing is:
Here’s your bulletproof vest. If it doesn’t work then bring it back and we’ll exchange it.
Think … about … it. (This really happened to me).
The Warptest POV
Whilst these are amusing to encounter they are also warning signs particularly for the Software Testing professional who works on projects. It is beyond importance to be aware of the work culture and management buy-in / comprehension of what Testing entails, why a specific tool or methodology is being recommended and whether all your efforts will result in a positive change or not.
When I was doing my certification as a Scrum Master the group were asked the best response to this scenario:
Your team are working successfully and to schedule based on their commitments. A manager walks in and takes two members of your team away mid-sprint. When you discuss changes to the schedule due to loss of resources the answer you get is, “We expect you to cope and meet the deadlines regardless”.
Many of the class came up with creative responses involving negotiation, refactoring schedules etc. but the Agile Coach giving the class responded,
“You are all wrong. You update your resume.”
There are software testing jobs like any other jobs that you simply shouldn’t take unless you are prepared for failure on the way.
Sometimes it is possible to pull a testing rabbit out the hat but it requires a strong team and most likely a high level of collaboration from the Developers you are working with.
Is this something unique to Software Testing or have you encountered this elsewhere?