Bug tracking Best Practices

Yesterday we went over Bug Tracking 101, aka the fundamentals every quality or development team needs to keep in mind when developing its very own bug tracking process. Now it’s time to talk about a couple of consecrated best practices for having an effective bug tracking process.

Beyond the fundamentals we’ve already talked about, it’s important to implement best practices if you wish to maximize product development as well as quality assurance. The idea behind the whole implementation of best practices is that – by having properly developed processes, completion checklists, and tests – a project can be rolled out and finalised with a lot less unforeseen situations than it’d have if done without any “rules”.

Best Practices for Bug Tracking:

Stick to your approach:


When you work towards developing an centralised, unified and independent approach for your bug tracking process, it’s of upmost importance to actually stick to it – after all, what’s the use of taking time to develop a process no one will use it?
All the teams involved in bug tracking need to follow a similar methodology – and use the same tool – to centralise your bug reporting and make sure the adequate steps to manage change are being followed.

As we’ve mentioned yesterday, Pipefy offers a great way to create you very own customised Bug Tracking process with the possibility of including detailed explanation for every step of the way, as well as required/mandatory fields that must be completed before your team is able to move the card further down the line.

It’s very, very important to involve and get feedback of everyone using your bug tracking process to make sure everyone understands it, knows how to use it and can focus on ensuring the success of the process.

Don’t complicate it:


Stick to the strictly necessary when choosing yourself a tool to manage your bug tracking process – it won’t do you any good to have a very sophisticated system to report bugs if people don’t take the time to explore it and learn how to use it.

Keeping it simple and making it easy for everyone to report bugs is essential – people need to be able to interact easily with the system with having to crack their heads open to learn how to use it – and getting frustrated when they can’t.

It may sound way too obvious to say this, but people tend to get overwhelmed when facing a tool with a lot of cool new features and feel like they need to be able to use all of it…and instead of making it simpler, the tendency is to over configure it and make it a lot more complicated than necessary.

Leaving all the complication aside and choosing an easy to use system will actually encourage people to participate in the bug tracking process – trust me, many many systems out there (such as Pipefy) can be made a lot simpler with a little workflow definition and some automation here and there.

The last thing you want is to adopt a tool that might end up frustrating and discouraging users who simply wanted to report and track bugs, instead of dealing with an overloaded, over-configured bug tracking system.

Make information available:


Remember what’ve talked about having all the information necessary back in the fundamentals post? It’s important to capture all the essential information during the initial steps of your bug tracking process so it’s every bit as important to keep the input system and its screens, if you’re using a digital tool, clean and easy to understand.

Developing a single screen with a ton of input fields of information that’s not even strictly necessary to that specific phase of the process may overwhelm your users. Let’s imagine you’re using Pipefy’s Bug Tracking Template: on your start form, you’ll ask for all the necessary information -which will then be easily accessible on all other phases of the process, on the left side of a card. Then, on the phases that succeed, you’ll have different fields asking for information pertaining this specific phase, and so on. All the information the users insert, in all phases, are available for consultation on the “What happened on the previous phases” part of your cards.

You know how people say “less is more”? Well, in this case, simplifying your process will make it a lot easier for people to understand and use it – but remember, make sure all the information needed to reproduce and track the bug’s change history won’t be left out.

Stick to what’s essential:


Your data input for capturing bug tracking information needs to be as clear as possible – the user must know what each field represents and what it’s asking for just by looking at it. It’s essential that, when initially configuring the system, the people that’ll be actually using it to report bugs are consulted to make sure the whole process is clear and there are no overly complex terms that may not be easily understood by everyone in the organization.

If the essential fields are not clear enough so users can understand them, it may end up with essential data being left off. Stick to what’s essential, adding a lot of complementary fields that won’t help developers track, reproduce, test and fix the bug is a waste of time – remove them or at least make their filling optional.

Be clear:


We’ve been saying it over and over again how important it is to collect relevant, important information, so I’m pretty sure you’ve understood the need to be clear, to this point – the tool you’re using to report and track your defects will be only as good as the information people put in it.

When the information is incorrect or incomplete, the teams responsible will end up wasting their time tracking down incorrectly reported defects or searching the missing information.

Be visual:


Application and software defects may have visual components that couldn’t be described with the necessary details so, instead of burning your brain cells trying to figure out a way to put in words, use screenshots to reduce confusion. Screenshots may be just what you need to simplify your bug tracking.

Report new things:


Having a bug reported is useful – having it reported 2, 5 or 10 times certainly won’t make it more useful. Make sure users track your defect database before opening a new report to make sure they’re not creating a duplicate.

Keep your defect database uncluttered and make it a lot easier to provide accurate representations of your product’s quality. Avoiding duplication will save users precious time they could spend researching for defects that have already been fixed.

We’re not saying people should not report a bug more than once, if it’s happening in different occasions – we’re just saying it should be done in an unified report.


Track your bugs with Pipefy:

If you’re looking for a simple and intuitive way to start tracking your bugs, try Pipefy! We help companies keep organised and more productive by running their processes and day-by-day routines on an easy and intuitive tool.

Pipefy’s Bug Tracking template offers you with the structure you need to report, prioritise and track all your bugs in a centralised, easy to use platform. It keeps all your reported bugs organized and helps you classify and prioritize them.

It comes with a detailed start form to allow your team to properly report all the details of the bug: the time it was reported, it’s severity, where it happened and a complete method to evaluate its impacts on the user experience and your business goals.

Written by Isabelle Salemme, Product content manager at Pipefy. She uses her extensive Pipefy knowledge to write informative pieces teaching users to make the best of Pipefy. Besides being responsible for all product-related content, she's an avid reader, a coffee lover and a professional photographer.