Is saying 'it was broken when we got it' still relevant?

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.


1 Like

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!

1 Like

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.

1 Like

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.