Wednesday, 10 July 2013

Bugs on Post-It notes

I like to write bugs on post-it notes. Simple ones, where I don't need a supporting screenshot or a log. It seems wasteful to put it in to a bug tracking system and nurse it through a process. I'd rather write it on a small, brightly coloured piece of paper, walk over to the developers and hand it to them, with a quick chat to check that they understand my scrawl.

The reaction to this approach from my project team has been mixed.

The developers seem to quite like it, as much as any developer likes receiving bugs, though they do joke of "death by a thousand paper cuts". Though it's harder to escape defects when they're lined up like soldiers along your desk, awaiting your attention, this approach feels more like a collaborative process rather than an combative one. Having to transfer the physical object increases the opportunity for conversation, and the communication between development and test is excellent. As the developers resolve each problem they take great pleasure in returning the associated post-it to me with a confident tick on the bottom. There's also a healthy level of competition in trying not to have the most post-it notes stuck to your desk.

Occasionally the developers will ask me for a defect number to include in their subversion commit comment for changes. "Oh, I didn't raise that one in the tool" I say, "I just wrote it down". Turns out this isn't a problem, they explain the change instead of referencing the defect ID, now the commit messages don't rely on a third party system.

The project manager was initially a bit miffed. "How many bugs did we fix in this sprint?" he would ask. Though this could be tracked by counting the number of post-it notes stuck on the visual management board as completed, as time passed he realised he didn't need that number as much as he thought. In an environment where bugs enter a tracking system it's important to track their life span, as they often live for a long time. It's pretty easy to ignore things that cannot be easily seen, however it's difficult for a developer to ignore a multi-coloured desk. My experience is that reported faults on post-it notes are fixed in a startlingly fast fashion, and as the answer to "How many bugs did we fix?" starts to become "All of them", the actual number loses significance.

In the small number of cases that I want to raise a problem that requires supporting evidence, I put this information in to the tracking system. I also write up the post-it with the defect ID on it, and go and give it to the developer. I want to keep as many of the good things about post-it defects as possible, while still providing enough detail to the developer that they can understand and resolve bugs. But the overhead in using the (very simple) tool convinces me that it's for special cases only.

Post-It notes are the best.


  1. Must admit- got love the satisfaction of putting pen to paper.

    Just curious, when the developer has dealt with your defect, how do they deal with your post-it note? Do they put it on a 'fixed'/'closed' board?

  2. For GUI issues, I've found it works well to just print the screenshot, highlight it and stick that to the board.

    1. But as we move to "Reducing Paper Waste to Save Trees" - How does this Printing the screenshots if there are bunch of GUI issues?

  3. Hi Nicola,

    The developer gives the post-it back to me. I check the fix, and then it goes in to the "Done" column on our Scrum board so that the Project Manager has visibility of how hard everyone is working ;)

  4. On a recent project, the devs weren't keen for the testers to deploy their code until it was "done", since they didn't want them raising defects.

    We got around it by agreeing that the post-it notes represented "feedback" rather than "defects". After all, it could be a bit rude to call something defective when it's not finished!

    In this way it's seen as another form of feedback in a similar vein to that provided by unit tests, automated checks etc.

    To keep everyone happy, we agreed to raise defects in the issue tracking system if bugs were found after the feature was "done".