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:
- 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.
- 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.