Have you heard this before?
‘The software was working perfectly fine until the testers got their hands on it’.
What about this?
‘Don’t give it to the software testing team. They’ll break it!’.
Are any of these claims actually true?
Can testers really break a perfectly good piece of software by running a few test scenarios and pressing a few buttons?
This is quite a common misconception because as testers, it is not our job to ‘abuse’ software and use it in a way that is going to increase the chance of it failing. It is also inaccurate to claim such things unless the tester has access to the source code of the application and can make permanent changes ‘under the hood’.
What testers actually do
A tester should always approach a testing project with the mindset that the system they are testing has hidden defects waiting to be uncovered. This is useful to testers (especially when performing exploratory tests) because having this mindset will encourage us to go deeper with our tests and ensure that we cover the length and breadth of the system.
But when a defect is discovered in the software and that defect is triggered. If a crash or some other error is the result. It would be inaccurate to claim that it was the fault of a tester.
Defects are coded into a piece of software, often the result of incorrect programming logic or incompatibility with the expected environment and are hidden behind the illusion of a perfectly good, working piece of software.
The job of a tester is to not only ensure the expected functionality is there and working. But also to issues that are already present in the software and bring them to the attention of developers.
The software might have been working before the testers got their hands on it. But the software was already broken. You just weren’t aware of it.
The inspiration for this blog post was another blog post called Testers Don’t Break the Software by Michael Bolton. Please read the original if you have a spare moment.