Your devs are great testers
--
I know what you’re thinking: NO!
No No No! Devs are biased and they’ll test the happy paths. They know where the “issues’’ are, they’ll work around them, they’ll… They know where the “if-else” is.
Yes, this is somehow true. Developer’s brains are formatted to “Development” and biased towards the code they wrote. This isn’t because devs are weird or have some human limitation. It’s how the human brain works. But, as any human being, their minds can be shaped.
Different strategies and roles
Let’s take a step back. There are numerous different quality assurance strategies and you should have them in place, like automatic tests (Unit, Integration, End-to-End, etc), manual tests (done by independent quality teams or in test ensembles), UX tests (where you identify experience failures) and so on. And you should have different roles in your organization related to testing (Quality Engineers that help define the path for Quality Assurance, quality teams that just follow testing scripts, etc). Of course, all this assumes your software needs it and you have enough money to do it.
But, even if you have the money to have all these safety nets in place that protect customers from headaches (and, ultimately, your image, reputation and business), there’s one tester that can be the best first line of defense. The Dev.
How?
It’s not by developing automatic tests (although one should, of course), but by USING the PRODUCT, not just the feature. Using as if it was a customer, going through the entire customer experience and not just the feature that was just implemented. This requires training, experience. It’s a different mindset.
An example
A color picker. Imagine a tool that lets you create Mobile Apps. It will ask for the app name, icon and primary color. So, color? Color, under the hood, is easily represented as an Hexadecimal value. Right, so, the developer implements a UI to capture the user’s input: an hexadecimal string.
