Spoiler: because they won't find the bugs.
At least not all of them. And precisely not the ones that then surface after go-live - at the worst moment, in the most expensive circumstances.
This isn't a criticism of developers. Quite the opposite: the best developers know perfectly well that testing their own code isn't worth it. Bugs are missed not out of laziness, but because of an entirely natural psychological phenomenon. Let's start at the beginning.
Confirmation bias - something everyone knows but few name
There is a classic psychology experiment. A group is asked to count the passes made by the team in white in a basketball video. The task absorbs their attention so completely that most participants simply don't notice a person in a gorilla suit walking through the middle of the video. (Similar effects: we tend to listen only to experts, or argue only with people, whose views match our own; we remember the things that are positive for us, and so on.)
Developer testing works exactly like this.
When developers test their own code, the solution is already in their head - they know how it was built and what they had in mind when writing it, and they unconsciously follow the paths the system can handle. The edge cases, the boundary conditions, the exceptional situations - where the system breaks - they rarely find. Because their mindset is the same one that created the bug. (In plain terms: they always click in the same place and use the same test data.) On top of that, their testing is not systematic - they only check the parts they touched.
This isn't a flaw. It is how the human brain naturally works.
Three cases I learned from (which turned into four)
Deploying an Oracle procedure in a billing system
Back in my systems analyst days, we wrote a new load procedure for an Oracle-based ordering and billing system - an automated loader for a new online channel. We were running late, so on Friday afternoon I tested the finished loader myself as the systems analyst, and the programmer checked it too. It worked perfectly; the whole process ran through. Great. We deployed it at around 7 pm on Friday and went home... And it really did work - BUT ONLY THE NEW FEATURE. NOTHING ELSE ON THE DATABASE WORKED. In 16 countries there was no billing, no online order processing, nothing.
We hadn't checked anything except the new function. (Because of dependencies, every procedure had gone "invalid".) It was a very complex system. By early the next morning we had managed to restart all the procedures.
An insurance claims notification app
We were working on a customer service mobile app for an insurer. The development team had done thorough work, run internal tests, and everything was green. We brought in independent QA for the final phase.
By the end of day one, our tester had found that if a customer received an incoming call in the middle of reporting a claim, answered it and then returned to the app, the process lost all the data entered so far - without any message. The customer could start all over again, with no idea why.
The developers simply hadn't thought of this scenario. Not out of laziness - but because they had tested the claims process, not phone interrupt handling combined with the claims process.
A workflow system for a leasing company
At an operating lease company, the developer tests for a workflow automation project all passed. On the first day, independent QA found that the system mishandled database communication for customer data containing special characters (accented names, hyphens). On the Hungarian market. With Hungarian names. Otherwise it worked fine.
The developers had worked with plain Latin-alphabet (English) test data. Natural enough - they "think in English" when they type test data.
A telephone IVR system
We were developing an online, phone-based IVR ordering system for an FMCG company ("press 1, press 2" and so on). Everything came together beautifully; the whole process and every feature worked. Then, within an hour of going live, it crashed. It turned out that when too many keypresses arrived at once, the server couldn't cope - this hadn't been tested, and the information we had about the number of concurrent calls was completely wrong. Far more calls came in than the design assumed. (There was no load testing. We hadn't even thought of it.)
The psychology behind it - why this is a structural problem
Independent testing isn't better because QA engineers are more talented than developers. It is better because their perspective is different. (They are generally much better at seeing through users' eyes and looking at the application "from the outside".)
An independent tester can spot different kinds of defects than someone working alongside the programmers, because they see the project differently - and can also spot problems that stem from the development team's way of thinking.
That is the key point. It isn't about the quantity of defects but their quality. The developer finds the defects that arise from the logic of the code. The independent tester finds those that arise where business logic and code logic collide - and those are the really expensive ones.
In financial services projects this is doubly true. With a defect in an insurance calculator, the question isn't whether the code is syntactically correct - it is whether the premium calculation logic matches the product description. The developer can't check that, because they don't know the product description in depth. A good QA engineer can. (Or, if not, they can consult the business analyst or product management.)
Another important difference between a tester and a developer: testing is the tester's job. They can plan testing far more systematically. Methodology matters for systematic work too (epics, user stories and so on).
"But our developers write unit tests too"
Yes. That's good. Unit tests find code-level defects.
But unit tests don't replace functional testing, integration testing and user acceptance testing. A unit test checks whether an isolated piece of code behaves as expected - not how the whole system responds to real user behaviour. (It is often suggested that testing by users is enough, but in our view most users lack the experience and systematic approach for it - and the same problem applies as with developers: it isn't their job.)
The car industry has a similar distinction: every component individually meets its quality specifications - and then, in the assembled car, running the air conditioning and the navigation at the same time drains the battery. Component-level tests won't find that.
When is developer testing enough?
To be fair: not every project needs dedicated independent QA. There are cases where developer testing really is enough.
If the project is short and well defined, the user base is small and homogeneous, the consequences of defects are low-risk, and there is fast feedback from production, developer testing is an acceptable compromise.
But if any of the following applies, independent testing is not optional:
- The system handles financial data - Hundreds or thousands of users will use it at the same time - Compliance or regulatory requirements are involved - A defect would cause customer harm, data loss or reputational damage - The system integrates with existing core systems
In financial services projects these almost always apply: high risk, a need for complete precision, and a large number of connections with other systems and processes.
What we do differently at FrontX
FrontX QA engineers don't join at the end of development. We work shift-left: the tester is involved from specification review, tests completed features in parallel during each development sprint, and doesn't try to find every defect in one huge final testing cycle. (Of course, there are cases where "only" the developers test during the development phase.)
This works because QA is not part of the development team - it looks at the system with independent eyes. There is no social pressure not to "criticise a colleague's work", and no incentive to cover up defects. What there is, is financial services industry experience - which means QA understands the business logic it is testing.
If you are looking for a senior QA specialist who understands financial services processes - or if you are a QA engineer who wants to work somewhere testing is a strategic role, not an after-the-fact check - see how we work: frontx.hu/en/careers
A question for you
Have you ever hit a defect after go-live that an independent tester would probably have caught beforehand? What was the most expensive "surprise" a live system has given you?
Frequently asked questions
Why shouldn't developers test their own code?
Because during testing, developers unconsciously follow the paths the system handles - not the ones where it fails. Due to confirmation bias, testing your own code is structurally limited: developers test with the same mindset they used to write the code. An independent tester comes at it from a different perspective and finds defects that stem from the developer's way of thinking.
What is the difference between developer testing and independent QA?
Developer testing (unit tests, integration tests) finds code-level defects. Independent QA finds defects that arise where business logic and code collide - it checks how the whole system responds to real user behaviour. The two don't replace but complement each other. (Obviously there is no point in a tester starting on a system that is still constantly throwing errors - that would just waste time.)
When is independent testing needed on IT projects?
It is essential if the system is highly complex or handles financial data, if hundreds of users will use it at the same time, if compliance or regulatory requirements are involved, or if the system integrates with existing core systems. In financial services projects these almost always apply.
What does shift-left testing mean in the context of independent QA?
Shift-left testing means independent QA doesn't join at the end of development but is involved from the start of the project - from specification review to parallel testing during development sprints. This drastically reduces the number of defects that have to be fixed later.
How is FrontX's QA approach different?
FrontX QA engineers work shift-left, with financial services industry experience. They don't just look for technical defects; they also check that the business logic is implemented correctly - and can spot cases where the system formally works but the outcome is impossible or illogical from a business point of view. You don't need to explain the insurance process, the lease contract lifecycle or banking compliance requirements - they already bring that knowledge.
About the author
László Behán is Managing Director and Co-Founder of FrontX Kft. He was previously CIO of Signal Biztosító, Head of Development and Data Warehousing at Groupama Biztosító, and Operations Director and a member of the Board at LeasePlan Hungaria. He has 25 years of IT and business leadership experience in financial services.
LinkedIn: linkedin.com/in/laszlobehan | FrontX insights: frontx.hu/en/insights
