Thereâs a common saying these days that testers donât break things, we just get things that are given to us broken.
Is this still true in a modern agile type environment? How can we say stuff like this and still be expected to be involved in the whole process of development? If we are involved in the whole process of development and product creation then surely we are partly to blame to have things given to us that are broken.
Thoughts?
It will always get to us broken, no matter how good the developers are or how much weâre involved. Thatâs just how code is, so it doesnât make sense to me to make a fuss about it - unless someone else is complaining that we broke it. Then it was broken when we got it.
I once got royally told off for saying I broke software. So I switched to saying I found the break point, so itâs now broken. Or itâs already broken, the dev just doesnât realise it. I think it depends more on the people youâre working with and the fragility of egos involved. Iâm happy to supply lots of information before hand, however, weâre not infallible and often I would think of edge cases when Iâm playing with the software itself. No one is to blame as such. Itâs just it can often require a certain set of circumstances to be in place for that idea to pop. Those are often the most satisfying bugs to find!
I think it kind of depends. If, for example, we are involved in the design process (as you would hope to be - it doesnât matter if the project is agile or not) and we donât see problems that then proliferate through to implementation then we canât say we are without blame for broken software.
If, in contrast, our help is refused or we are actively shut out of the design process then we are in the unhappy situation of having broken product pushed on us.
As you rightly point out if we have a good, functioning agile process then we will be involved right from the inception of each feature and therefore we can shoulder our portion of the blame. What we need to be careful of is that we are not entirely to blame, we only share joint culpability.
Iâve been in the situation where I was actively bared from consulting key stakeholder groups until too late in the process, and no matter how I presented what an issue this may cause I was still denied access. As you can guess, one of the stakeholder groups I tried to consult then raised issues with the design which caused delays for rework. Was I without blame for broken software? Possibly - I couldnât find a way to persuade senior managers that the access was crucial to a timely delivery, but I did repeatedly raise the flag so I didnât feel too bad.
Thereâs a chain in a bug - a threat exploits a vulnerability that causes a problem to a victim. Or something external to the product (threat) happens and because thereâs a vulnerability (something in the product that permits problems to happen under certain conditions) then it causes a problem (something the product does that it shouldnât) to a victim (someone who feels the impact of the problem).
âWe break softwareâ means âWe create the threats that expose vulnerabilitiesâ
âWe get broken softwareâ means âThe software has vulnerabilities created by our clients and never by us, we just find themâ
This is why both sides of the argument are certain that they are right. Itâs the blue and gold dress all over again.
If you say âtesters break softwareâ then you take on some responsibility for the fact that you broke it - you donât look like a sceptical investigator reporting on a situation you look like a dick with a hammer cocking up everyoneâs work.
If you say âitâs broken when we got itâ then you look like a dick thatâs shifting that blame to your own test clients.
So say neither, itâs a false dichotomy. Stay away from the work âbreakâ in a software-at-work context. It doesnât even make sense - what would it mean for software to âbreakâ anyway? The wordâs a shortcut to too many meanings (meets quality standards, meets requirements, capable of working, has a bug, etc) to be useful in professional communication.