Let’s all admit this: Testing our work is not very exciting!
Go on Admit it!
I think there are several reasons for our reluctance to test:
- We naturally test the new feature that we are coding, just for the satisfaction of knowing that it’s done.
- Repeated testing of the same feature gets boring real fast, and besides, we already tested it and it worked.
- Our users will test it for us and tell us if it’s broken.
- We have not been taught how to thoroughly test our work.
- We build incrementally and (should) test as we go, but we don’t tend to go back and test everything again as a whole.
- We add new features which can break the older parts.
- We focus on getting the job done and moving on, usually because of time or cost pressure.
- And many more things.
Reflection time
As you read those reasons, I imagine that some of them resonated with you as you realized that you probably think that too. Good!
Other reasons may not seem true to you, and that’s good too.
Feedback time:
Go to the bottom of the page and leave a comment please about those thoughts, and please if you think of others I did not mention, then add them to the list. Thank You.
Please go read this article and see what you learn:
Developers are Not Good Testers – Really
Please leave another comment about what you learned from that reading.
Done done.
Some development teams use more precise metrics on the state of their work.
“Done” means that it has been shown to work, and it’s time to move on.
“Done” is often the primary focus of the developer, and rightly so. However he often lacks access to proper testing tools or environments, which can discourage thorough testing.
The testing team equips itself with the most relevant tools, environments, and techniques. These often change as fast as the development tools.
Finally, creating good communication channels between testers and developers that have low friction ensure that both can do their jobs in an atmosphere of trust and interdependence.
But “Done done” means it has been code reviewed and tested by another developer or better yet a dedicated testing expert, and it’s been documented. In other words it is done in every way we can think of.
When the whole team works properly, then Done goes to Done Done quickly and the team succeeds as a whole.
Testing table of contents:
The rest of this page will be a table of contents to other sections about testing
Future sections:
- Types of UI testing
- Interactive UI testing
- Automated UI testing
When you have completed reading those resources, pause again here and leave comments on this page. This is a team effort, and your insight is valuable to the rest of the team.
Next Page –> Fundamentals of testing
The reason I think developers sometimes resist code reviews and testing is that many of them tie their identity to their code. So when you say, “someone should review this,” what they actually hear is, “you probably made a mistake.” Even if you didn’t mean it that way. Even if you said it politely. Humans are fragile creatures with keyboards.
Another issue is the false sense of completeness. Developers run the code, it works, there are no errors, so they feel it is ready to be shipped. The problem is that it only works for them, in one scenario, and on their own machine. They confuse “it runs” with “it is correct,” which is dangerous.
There is also the ownership mentality. Developers often think, “this is my feature,” so external review can feel like an intrusion, a loss of control, or unnecessary interference. They sometimes forget that code review is actually a way to reduce risk, not criticize their work.
Bad past experiences with reviews also play a role. If reviews were too nitpicky, overly aggressive, or too slow, developers may start seeing them as useless friction. In some cases, that perception is understandable.
Another factor is overconfidence in testing. Some developers believe they have tested everything thoroughly, but in reality, they often miss edge cases or unexpected user behavior. Humans don’t naturally think in terms of chaos, but users do.
Finally, there is often a lack of a clear definition of what “done” really means. Without a shared understanding of “done done,” developers may assume their work is complete when it has not been properly reviewed, tested, or documented
It’s true: we often get caught up in the excitement of finishing a feature and forget that the hardest part is not breaking what’s already working. I definitely recognize myself in the boring side of repetitive testing when we’re pressed for time. it’s a great reminder of our bad habits.
I have learned that the reason developers are often not the best testers isn’t due to a lack of technical skill, but rather a fundamental difference in mindset. While developers focus on constructive logic (how to build), testers focus on destructive logic (how to find flaws).
I also discovered the concept of ‘motherly affection’ toward one’s own code, which creates a natural bias that makes it difficult for a creator to spot their own mistakes. hence the importance of independent tests to cover negative scenarios.
Understanding software testing is crucial for developing reliable and professional applications.
One key takeaway for me is that software testing is not just about evaluating whether an application functions as expected and meets specified requirements; it is a vital discipline that guarantees quality and reduces risks that could damage a product or reputation. As part of this team effort, I would add that by tracking bugs and identifying gaps, we can find issues early and provide a seamless experience for end-users.
Another insight I gained is that testing should focus on four main areas: functionality, performance, security, and usability. In the end, I believe testing is the most effective way to achieve better results, improve system maintainability, and deliver a top-notch and reliable product.
I recognize myself in many of the points mentioned, especially the tendency to stop testing once a feature works the first time. There is often a silent assumption that “if it worked once, it will keep working,” which is not always true.
What this article reveals to me is something deeply human: we naturally avoid repetition, we seek quick completion, and we tend to protect our effort instead of challenging it. Testing, especially repeated testing, feels less rewarding than building something new, so we unconsciously neglect it.
I also resonate with the idea that we focus on progress (adding new features) more than stability (ensuring everything still works). This creates a hidden risk in our work.
From the comments, I learned something very important. As Gauthier mentioned, there is an emotional connection between developers and their code. That “identity attachment” can make external testing or review feel like criticism. Théophile also highlighted how repetitive testing feels boring under time pressure, which is very real. And the idea of different mindsets between building and breaking systems reinforced this reflection.
My personal takeaway is that testing is not just a technical discipline, but a discipline of humility and responsibility. It requires accepting that what we build is fragile and must be constantly challenged.
In terms of action, I want to move toward a more result-oriented approach:
– Not stopping at “it works”
– Intentionally testing negative and unexpected scenarios
– Re-testing older features when adding new ones
and progressively adopting the idea of “done done” instead of just “done”
I believe this shift can significantly improve the quality of our work as a team.
Well said, you read it deeply and identified with this opportunity.
The hidden risk has a name: Technical Debt.
We will address that as a team later. It is essential to recognize and remember and proactively address technical debt.
@Salomon: I just added a page on Technical Debt is a valuable tool.
What I understood from this article is that the limitation of developers in testing is not mainly technical, but psychological and behavioral. Developers and testers operate with fundamentally different mindsets: one is focused on building correctly, while the other is focused on finding what can go wrong.
The concept of “motherly affection” toward one’s code really stood out to me. It clearly explains a natural human bias: we tend to trust and protect what we create, which makes it difficult to critically evaluate it. This connects well with what was shared other in the previous discussion about identity and ownership.
Another key insight is the difference in approach. As developers, we tend to follow structured and logical flows, while testers intentionally break that logic by exploring unexpected and chaotic user behavior. This shows that testing is not just verification, but exploration.
What I also learned from others’ reflections is the importance of external perspective. A different person interacting with the same system can reveal issues that the original developer would never see. This reinforces the idea that testing should not be isolated.
On a deeper level, this article reveals something about human nature: we are not naturally wired to look for our own mistakes. We tend to validate rather than challenge ourselves. That is why relying only on developer testing is risky.
In terms of practice, I want to become more intentional in how I approach testing:
– By consciously shifting from a “builder mindset” to a “breaker mindset” during testing
– By testing negative cases, not only successful scenarios
– By imagining unpredictable user behavior
– And by welcoming external testing and feedback as a way to improve, not as criticism
My goal is not to replace testers, but to reduce this natural bias and contribute to more reliable and robust applications.
By mixing the ideas from this page and the article about *developers being testers*, I understand something from my own experience with Frontend Mentor challenges.
It is very hard for a developer to find their own mistakes. First, we think we are already testing while coding. I do the same. But then, suddenly, I see corrections from my mentor, and I realize I missed many things.
Also, I feel attached to my work. Because of that, I do not judge it in a fair way.
Second, I do not always have the skills to test properly. Real testers know common mistakes and where problems usually happen. That helps a lot.
Lastly, there is the problem of time. Sometimes I just want to finish and move on, instead of checking everything again.
Another important point is that testing shows reality. As humans, we do not like to face our own mistakes. It is not easy to accept them.
Hopefully, I read that it is possible with awareness and time, for developers to learn the skill of testing which will better their results
This article highlights a reality that many developers can relate to: testing is often neglected, not due to lack of skill, but because of limited motivation, time constraints, or lack of proper methodology. The reasons listed are very accurate, especially how repetitive testing quickly becomes boring, or the tendency to rely on users to discover bugs.
What stood out to me the most is the distinction between “Done” and “Done done”. It clearly shows that finishing a feature is not enough — it must be reviewed, tested by others, and properly documented to be truly complete.
The article also encourages self-reflection, which is very valuable for improving one’s development practices. One additional reason I would add is that developers do not always have access to proper testing tools or environments, which can discourage thorough testing.
Overall, this is a great reminder of the importance of testing in software development and its critical role in delivering high-quality applications.
Thank you for your comments.
Your comment that “developers do not always have access to proper testing tools or environments, which can discourage thorough testing.” is insightful and I will immediately add it to the page.
It is not limited to testing tools or environments, but extends also to a focused perspective. Since testers focus on the product from the user point of view they isolate the testing from the developer’s “how do I build this?” perspectives. This is a key example of the separation of powers.
The difference between Done and Done Done is the combined efforts of the whole team. A developer can only get it Done, but the team working together is focused on Done Done.
This article reminds us that as developers, we often tend to rush through a feature instead of taking the time to learn and understand each step. Under pressure, we may move too quickly, repeat actions without thinking, and rely on visible results rather than real learning. It is therefore essential to stay diligent and fully grasp what we are doing, even if it takes more time.
This text highlights a very human reality in development: we naturally tend to prioritize building over questioning what we have built.
I strongly relate to the idea that “if it works once, it’s good enough.” In reality, this reflects a confusion between functionality and reliability. Testing requires a different mindset, almost the opposite of development: instead of building, we actively try to break things.
The concept of “Done” vs “Done done” is particularly powerful. It shows that product quality is not just about individual effort, but about collaboration and shared responsibility within a team. It also introduces discipline and humility in how we approach our work.
Finally, this text helped me realize that testing is not just a technical step, but a skill in itself, requiring method, rigor, and a shift in mindset. It is a key factor in moving from “working code” to truly professional and reliable software.
Great breakdown. I think we also struggle with Emotional Attachment; nobody wants to find a fault in something they just spent hours perfecting! Point #7 (cost/time pressure) is definitely the biggest culprit in my experience.
I really liked the distinction between the ‘positive scenario’ focus of developers versus the ‘out-of-the-box’ thinking of testers. It’s a great reminder that while developers should learn testing to improve their craft, professional testers bring a unique, critical perspective that can’t be replaced. https://www.geeksforgeeks.org/blogs/developers-are-not-good-testers-really/
Thank you for this necessary reminder. The reasons for our reluctance (boredom, time pressure, overconfidence) are very well identified. The additional links, especially on why developers aren’t always good testers, add great value to the discussion.
I liked the analogy given in article that assume that trying to understand why developers are not really good testers is like asking ourselves why do students don’t check and evaluate their examinations by themselves, that explained why I was finding all the reasons given in this page and in the same article, so obvious and natural.
Although, as Alain Bahane said in his comment, developers (including myself ) think they’re “testing” their work, but we quickly see why this is not testing properly speaking.
Therefore, I’d like to highlights two things as takeaway, beyond all that has been shared here:
– Shifting our mindset as users and
– Having access to appropriate testing tools
Thanks Michael and all the mentors, for making us aware of this reality and for helping us to be good testers.
No matter how skilled I am as a developer, I will never catch every issue in my own code. Understanding this will make me more open to collaboration and feedback from testers. Instead of seeing testers as people who “judge my work,” I have to see them as partners who help me build better, cleaner, and more reliable software. I experienced this with my mentor. My mentor’s findings were not a criticism, but rather a contribution to my success.
Even with testers, I still need to write good unit tests, validate edge cases, and think critically about my code.
I really resonate with the distinction between Done and Done Done; pushing for that extra layer of peer review and documentation is what actually keeps a project from breaking as it scales.
One thing I’d add to the list of why we skip testing is “The happy path bias”.
We naturally want to see our code succeed, so we often forget to test for the weird, edge-case ways a user might actually break it.
The assertion that developers are inherently poor testers captures a fundamental truth about cognitive bias, yet it oversimplifies the evolution of modern engineering standards. While the “creator’s bias” makes it psychologically challenging for developers to identify their own logical oversights or anticipate erratic user behavior, the industry has largely bridged this gap through automated frameworks and Test-Driven Development (TDD). Professional testers remain indispensable for their specialized ability to explore edge cases and validate end-to-end user experiences from an objective perspective; however, a developer’s proficiency in unit and integration testing is now considered a core requirement for high-quality software delivery. Ultimately, the most robust applications are the result of a collaborative ecosystem where developer-led verification and independent quality assurance complement one another rather than operating in isolation.
Really enjoyed reading this testing is something I’m actively learning to take more seriously in my workflow.
I like how you explained that it’s not just a final step, but something that should happen throughout development. In my case, I mainly rely on manual testing checking user flows, validating inputs, and making sure everything behaves correctly across different scenarios.
Working on web apps (with PHP, JavaScript, and handling things like file uploads, notifications, and user roles), I’ve noticed that a lot of issues only show up when you actually use the app like a real user. Things like edge cases, permissions, or unexpected inputs can easily slip through otherwise.
I haven’t started automated testing yet, but I can definitely see how important it is as projects grow.
Thanks for sharing this really helpful and relatable
Testing feels boring until something breaks then it suddenly becomes the most important step. The truth is we don’t avoid testing because it’s useless, but because it’s repetitive and often undervalued under pressure. Maybe the real shift is seeing testing not as a final step, but as part of building something reliable from the start.
Developers and testers think differentlyand that’s actually a strength, not a weakness. I’ve learned that developers focus on making things work, while testers focus on breaking them to ensure they truly hold up.
That difference in mindset shows why both roles are necessary. The key takeaway for me is that even if developers aren’t perfect testers, improving testing awareness can still lead to better, more reliable software.
We love to create, but we neglect to verify. Often, we believe our code will work simply because we designed it with logical intent. Humans are generally poor at repetitive tasks, so testing is perceived as a cost rather than an investment.
Failing to look back and test the system as a whole is the primary cause of production failures. Sometimes, we don’t test out of fear of finding something that would jeopardize our entire architecture; either test automation makes the exercise more exciting, or it remains just another form of drudge work.
I found this article very insightful because it highlights something many developers, including myself, can relate to—the tendency to focus on “it works” rather than fully validating the solution. The idea that repeated testing can feel boring is true, but it also shows why testing is often overlooked, even though it is essential for long-term stability.
The distinction between “done” and “done done” is particularly important. It reminds us that real completion is not just writing code, but also ensuring it is properly tested, reviewed, and documented. I also appreciate the emphasis on collaboration between developers and testers, as good communication can greatly improve the overall quality of a product.
Overall, this reading helped me see testing from a different perspective and reinforced its importance beyond just a final step in development.
I have read “the types of testing”, I have discovered that there are five types of testing or even more. Each type is used differently in its context with its benefits and disadvantages.
I was also happy to read that there are AI tools to help better the work of a tester. Before we have to understand how testing works
During my Reading I undestood this : the software development lifecycle that involes evaluating and verifying that a software application or systeme meets the requirement and functions correctly.
Effective software testing pratices not only improve the product’s reliabulity but also enhance user satisfaction and reduce development costs.
The best pratice for software testing is :
Plan your testing
Testing throughout the life cycle
Grasp negative testing
Adopt automates testing
Adopt test – orientated development practices
Broad coverage of different Test Areas
Testing on actual (in-real) devises
Independent Test cases per feature
Adopt regression testing
Try and user testing
In the competive software market producing a high quality, user friendly product is essentiel for maintaining a strong position.
Implementing effective software testing practices is crucial to identifying and fixing bugs ensuring performance, and decivering a reliable software product