(Page 2 of 4)
BEST PRACTICE #2: DEFINE YOUR PROCESS, AND MAKE SURE IT’S UNDERSTOODCreating a process for dealing with defect fixes offers efficiencies and can be tailored to how an organization likes to work.
The process, though, “is more complicated than being a state traffic cop,” offered Rich Bianchi, CEO of software provider Alexsys. “All this is a workflow problem that might be multi-faceted.”
Alexsys’ tools can be customized to enable users to create different forms, layouts and requirements for different types of defects, each of which might kick off a different workflow. “Depending upon your product, you might have different selections; you can select different people” to be in the workflow, he said, while targeting different types of bugs for different builds.
Meanwhile, Axosoft QA engineer Michael Robinson said terminology can be an issue if the items in the software are not called the same as terms used among the working groups, which can lead to a lack of understanding. If you’re using Scrum as a development methodology, he said, you want the tool to call work items “user stories” and “product backlog,” for example, instead of “defect” and “feature.” Customizable fields are an important feature in defect-tracking tools, and most allow those changes to be made, according to experts.
Seapine’s Rome cautioned, though, that it’s important “for everyone on the team to know that the custom field means. You need to take the time to agree on step 1: what a ‘bug’ means.” She went on to say that when organizations have been doing something for a while, it’s easy to add custom fields to the tools. But after a process is a couple of years old, it’s important to make sure you’re adjusting the process. “It’s not that the (defect-tracking) system isn’t working anymore, but it has changed. Organizations think at the time the custom changes are great, but they never revisit it, and you end up with a bloated system.”
Atlassian’s Nolen discussed the notion of warranty bug fixes. “If your team built a feature, it is responsible for bugs, even if you’ve moved onto something else. This gives other people in the company dealing with the feature someone to go talk to,” he explained. For non-warranty bugs, which usually involve projects more than 10 years old with large feature surfaces, defects go into a backlog, and a person or team then cranks through them as quickly as they can. “It’s important that somebody is trying to make some dent in that backlog,” he said.