I have recently observed myself and others having a variety of reactions when defects are found ranging between the extremes of elation and despair. How should we feel when defects are discovered? Should this vary by role?
I will first answer this question on a role by role basis, starting with the role of tester. Since one of the primary objectives and professional skills of testers is to find defects, I would expect them to generally be happy when they find problems. The more significant (e.g. critical) the defect or more tricky to find, the happier I would expect them to be. If the defects are trivially easy to find, or are so serious that they prevent further testing, then I could see testers getting upset because they are prevented from exercising their craft to the fullest level of their capabilities.
What about developers? When developers find defects in other people's code, perhaps via a code review, this is fairly similar to the tester role above so I would expect developers should generally be happy in this scenario.
When a developer finds a defect in their own code as part of the development process - e.g. by having an automated test that unexpected fails after a code change then how should they feel? It is only natural to feel some disappointment at having made a mistake, but I do not believe this is the best reaction. In fact, it may be harmful. If you experience mild distress or pain whenever you find your own defects, you may subconsciously start to try to avoid the pain by, for example, doing less testing. So I believe a better reaction is to be happy when you find your own defects. This may seem challenging to do, but consider these rationale:
- Finding the defect validates your skill at performing whatever defect detection activity you were doing - whether it was automated testing or personal code review - and reinforces the value of performing that activity.
- Discovering this defect provides a learning opportunity on how you might better prevent or detect this type of defect in the future. Learning opportunities are good.
- As a professional, you want to pass along high quality code. Every defect you find in your own code is one less defect others will find, thus raising the quality of your final output.
The final scenario to consider is when someone else finds defects in the developer's code. A typical example is when the developer considers a feature finished and a tester is testing it. Now this must be bad, right? Even more than the prior scenario it seems natural to feel disappointment. Each defect that is discovered is essentially downgrading the quality of what you have produced. However, some of the reasons we listed previously for feeling positive still apply. In particular if the defect was still found within the team rather than being passed along to the end user or client, then this is a good thing. It can be hard to see this as a developer when it is your code at fault.
So let us consider the final role: that of the team lead or manager who is supervising activity rather than specifically doing coding or testing. This role has no personal stake in individual defects, but instead is typically concerned about the broader implications to the project or product. Assuming that high quality is a key objective, how should such individuals feel about defects? One tendency is to react negatively because of the extra effort and schedule time required to fix defects. Finding too many defects can also lead to alarm bells over the level of quality. I feel that since the team lead or manager essentially represents the whole team, their reaction should correspond to the perspective of the entire team.
So what should the attitude of the team as a whole be to discovering defects? To properly answer this question we need to know what the team's objective is. I am going to assume it is to build working software that is being used and meeting users' needs. The existence of defects is clearly bad since they threaten this objective. But what about the discovery of defects? Discovering a defect means the team gains more information about the state of the software which it will typically use to improve the software by fixing the defect, and which the team can also use as feedback to improve.
Discovered defects exist prior to being found, but the team does not know about them until the time of discovery. This means that the team should experience simultaneous conflicting reactions: happy that the defect was discovered, yet unhappy that the defect exists.
So what should the attitude of the various individuals on a team be towards defects? Should it be based on their role? I believe that in an ideal team every individual will understand and adopt the common objectives of the team. This means that everyone's attitude towards defects should ideally be the same, no matter what the role.
As I have observed, in practice attitudes tend to be quite far from this ideal state. People maintain their own personal objectives and viewpoint in addition to or instead of the team's. Often they do not appreciate the distinction between discovering defects and the existence of defects. To correct this I believe team members need to be clear on the team's objectives and understand how the existence and discovery of defects impacts these objectives. I hope this article will help in that regard.
If you find this article helpful, please make a donation.