There’s a bit of a false dichotomy going on when people talk about “Tester” vs “Developer” mindsets, almost assuming that only one or the other can exist, but not both.
In reality, however, they are a collection of characteristics that someone has bundled together and labelled a “Fill-in-the-blank Mindset.”
Here’s a list from an article on mindset. See if you can identify if its a “Developer” or a "Tester mindset
- Take it apart to see how it works
- Solve problems
- Decompose
- Automate
- Compose
- Generalize
- Abstract
- Craft
Here’s another list from another article
- Being proactive and asking the right questions
- Being curious, collaborative, challenging and diplomatic
- Being creative
- Learning and knowledge transfer
- Test Automation
Without clicking at links, can you tell me which is which?
The answer to that is “probably not.”
The whole reason we are even having the discussion of “tester” or “developer” mindset, is because we as an industry have gotten complacent with developers writing shitty code.
Let me explain.
Here’s what people usually mean by “Tester Mindset” - A person who thinks about how stuff might break when they’re working on that stuff.
Here’s what people usually mean by “Developer Mindset” - A person who writes happy-path code and thinks about how to make things work.
Sometimes, people write long lists about mindsets (see above) that go beyond these two things, but anything outside of these two items are just generic good things that any person should do - regardless of their role in software.
And here’s why this distinction of builder/breaker makes no sense: A developer who writes code that is not resilient to how stuff might break not writing good code. A developer must necessarily think with a “testers mindset” in order to write good code. If they don’t - they’re writing shitty code.
A developer that is creating an input field on a web app, must necessarily think about input sanitation, including sql injection, sting length, and a host of other naughty strings.
A developer that is interfacing with an external, or internal API, must necessarily think about how the API may malfunction and write code that handles the API being unresponsive, or returning with an unexpected response.
A developer that is writing a class that interfaces with a filesystem must necessarily think about how to handle missing files, already existing files, locked files, missing directories, permissions issues and a host of other I/O issues.
If the they want to write good code, a Developer, while developing with whatever developer mindset they have, must also think about how stuff might break and thereby also have a “tester mindset.”
And because it is virtually impossible to separate “developer” and “tester” mindsets into two separate things, especially while writing good code, I find the terminology of “tester” or “developer” mindset to be misleading.
But for too long, we’ve let developers write crappy code, thereby requiring an army of testers to come after them and write a bunch of bugs, so that the developer can go back and re-write the code to be less crappy - and its all because we’ve gotten complacent with the crappy output some developers provide.
And not only that. We’ve encouraged it. We moved “quality” to be a QA teams responsibility and gave a free pass to developers to just write stuff w/o thinking about quality. After all, there’s a whole team over there whose job title and role is to think about quality. They’ll take care of it. Why would developers overstep their bounds?