Should developers verify their own bug fixes?

This is my attempt at starting to document this discussion I am having in my life about if developers should check their own bug fixes?

In my previous job, we worked very differently to how the teams I work in now work. Not only because my previous teams worked in Continuous deployment and delivery  compared to a more rigid 2 weekly release cycle, it is also partially due to the fact that I now work on projects rather than a product the company owns and develops and maintains through and through. The projects can be anything from 6 weeks to 2 years long with the long term projects being a newer thing.

In the old job we were 2 testers across around 2 product teams and our time had to be used in the most useful and productive way. One task traditionally executed by testers is to verify bugs are fixed. I had forgotten about this because I hardly checked bug fixes in the last 2 years. Why did I not verify bug fixes for 2 years? Well, one argument is that in general a bug report has a well defined steps to reproduce and an actual and expected result. Hence anyone should be able to check if the bug is fixed. Why not the developer? It hardly takes testing expertise to check a bug is no longer happening. With verifying bug fixes off of my plate, I could use my time doing exploratory testing of new features and user journeys through the application. I would of course still log bugs and discuss them with developers, but there was less of the bug fix ping pong going on.

Now with me changing my job, I saw an opportunity because a big time sink of the few testers I now work with is doing bug verification. I tried to argue that maybe they should not be testing the bug fixes but it should be the developers’ responsibility to test their own fixes. I heard some interesting pros and cons for this internally and through twitter as well. So here we go:

Pros:

  • Frees up testers’ time to do actual exploratory testing. Bug fixes could be classed as “checking” and the bug reports should be clear enough for anyone to check the fix.
  • Trust – no-one wants todo bad work and a bit of trust goes a long way for good team dynamics.
  • If developers do more testing, they may find ways of making it easier/faster by writing scripts or little tools, that the test team may not have the skills for doing on the fly.
  • It may lead to more pairing to avoid bugs in the first place.

Cons:

  • Lack of trust – historically bugs were not fixed properly and there may not be trust that the developer completely fixed the bug.
  • Would you check your own homework? Devs testing their own code is frowned upon, does this also apply to bug fixes?
  • Is it really fixed if no-one else has seen the fix?
  • What about knock on bugs that appear as a result of the fix?

 

What are your pros and cons for verifying bug fixes? Do you check bug fixes? Does it take away from your time testing the application?

I do think there is an element of “it depends” here as well. And this applies to the severity of the bug and the further risk of something else being wrong after the bug fix. But I would hope that someone checking a bug fix would notice if something else was wrong but maybe I have worked in very trusting environments the last 2 years and I need to re-adjust my thinking.

Advertisements

7 thoughts on “Should developers verify their own bug fixes?

  1. We all need another pair of eyes. Of course developers should check bug fixes. The better question is who else should also check it. Could be another developer, could be a tester, could be someone else. I assume developers at least check that their fix worked, and would be shocked & disappointed if they didn’t. I would feel like they had a low standard for themselves if they didn’t even try the steps to see if their fix worked.

    For example, did you know “own” is spelled as “won” in the first sentence in this post?

    Like

    1. Hey! Thanks for your input! I think I have seen that developers do not test their fixes and throw it over the wall to test and that is what has motivated me to be a bit provocative about this topic.
      Thanks for finding the mistake, I often get “now” and “know” wrong as well. Plight of English as a second language. 🙂
      But yes a second pair of eyes is so useful in so many situations and if possible I would love for people to pair and review work all the time.

      Like

  2. In my opinion it is more about what is the risk in the first place? So if the bug is not properly fixed what would happen? Based on that you can argue if always another pair of eyes is needed.

    Having a bug not fixed properly and coming back to the developer again and again is a lesson on it’s own )

    Liked by 1 person

    1. Would an incorrect fix be a communication issue though? I think clear reports and a good relationship in the team should help with that. If you cannot be sure you can fix the bug as requested or don’t even understand the report you shouldn’t attempt to fix it and speak to team members.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s