Denshin / Blog / Testing
Why developers should not be the only people testing their software
Developers test the path they built. Users take a different one. What an independent testing pass actually covers, what a useful bug report looks like, and when a separate QA team is overkill.
Denshin Team · Quality Engineering · 15 October 2026 · 4 min read
A developer who has just finished a feature has tested it. Usually properly. They clicked through the flow, checked the happy path, tried the obvious bad input, maybe wrote a unit test or three. And then the client finds a bug on the first afternoon, in a part of the screen nobody on the team thought to touch.
That isn't carelessness. It is how knowledge works. The person who built the form knows the phone field expects ten digits, so they type ten digits. They know the discount only applies after the cart is saved, so they save the cart first. Every test they run is shaped by what they already know about how the thing is supposed to behave. Users know none of it.
The path you built and the path people take
We think of it as two maps. The developer has the map of the code: which function calls which, where the edge cases live, which branch handles the error. The user has the map of the task: I need to raise an invoice for a customer who paid half in advance, and I need to do it before lunch. The two maps overlap a lot. The bugs live in the gaps.
Some things that tend to slip through when only the builders test:
- Going back. The user fills in step three, hits the browser back button, changes something in step two, and goes forward again. Half the state is stale.
- Two tabs. The same record open twice, edited in both, saved in the wrong order.
- Real data. Names with apostrophes, addresses with three lines of landmark directions, a product description pasted from Word with smart quotes and a stray tab character.
- Roles. Everything works for the admin account the developer logged in with. The sales executive account sees a button it should not, or misses one it needs.
- The second feature breaking the first. A change to the tax calculation on the quotation screen quietly changes the totals on an old report nobody opened this sprint.
None of these are exotic. They are just outside the path the developer was holding in their head while writing the code.
What an independent pass looks like
When we validate software, whether someone else built it or our own team did, the testers start from the requirements and from the way the business describes its own work. Not from the code. The pass itself is deliberately boring:
- Functional testing against what the software is meant to do, screen by screen and role by role.
- Integration checks wherever the product talks to something else: payment gateway, email, an ERP, a government portal, a WhatsApp provider. This is where the sandbox behaves differently from production.
- End-to-end runs of the real business flows with realistic data. Enquiry to quotation to order to invoice, rather than "create quotation" in isolation.
- Exploratory sessions, time-boxed, where a tester tries to break things on purpose and writes down what they did.
- Regression. Every bug that gets fixed becomes a check, and the checks run before each release.
The output is mostly bug reports, and their quality matters more than their count. A good one has the build or URL, the account and role used, exact steps, what was expected, what happened, and a screenshot or recording. A developer should be able to reproduce it in two minutes without asking a single question. "Invoice page is broken" is not a bug report. It is a mood.
The other output, the one people forget to ask for, is the regression suite itself. Whether it is a written checklist or automated browser tests, it should outlive the engagement and belong to whoever owns the product. Otherwise the next release goes back to being tested by whoever happens to remember.
This is not about developers being bad at testing
Our developers write tests and we expect them to. Unit and integration tests catch a lot, cheaply, close to the code. An outside tester does not replace that. They are a second pair of eyes that does not share the first pair's assumptions, for the same reason a writer should not be the only person proofreading their own copy.
There is a social side too. A developer reporting their own bug is admitting a mistake. A tester reporting it is doing their job. The second conversation happens earlier and with less friction, which means the bug gets fixed while it is still cheap.
When it is overkill
A five page brochure site with a contact form does not need a separate QA team. Someone careful clicking every link on a phone and a laptop, and sending a test enquiry, covers it. We run a short version of that on everything as part of our pre-launch checklist.
Independent testing starts paying for itself when any of these are true: money moves through the software, different roles see different things, the product connects to outside systems, or a bad release means somebody's operations stop for a day. Most business software ticks at least two.
If you want an outside team to test what your developers built, it is one of the things we do. The details are on our services page.
Tags: QA, Software Testing, Independent Validation, Regression Testing
All posts · Work with Denshin