nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

bugs during story testing

sudhir_utytrv

We are transitioning in to Jira from TFS. In TFS we used to log bugs during story testing. I know we can do the same in JIRA however I would like to see what others are doing in Jira as far as bugs during Story testing. how are you logging it in Jira...for example...as a bug and linking it to the story or something else?

I would like to know you methods for tracking and visibility on these bugs.

BTW we are trying to follow scrum agile

thanks

Comments

Nic Brough -Adaptavist-

I've seen two broad methods used for this. The short versions are

Bugs as stories (sometimes in the same project the original story was in, sometimes in other projects)
Bugs as sub-tasks

If you are doing Scrum, the first option is a lot easier to work with in Jira. This is because sub-tasks effectively add work to the sprint, and if that happens, you're throwing numbers off, and not being at all agile. Even if you mangle some numbers (for example assuming that 20% of a sprint will be bug-fixing stuff found during the sprint), it fails - imagine you find a bug 5 minutes before sprint end - you've brought more work into the sprint and you're going to fail to complete it. So bugs are easier to handle in scrum if you treat them as stories in their own right - you can plan them straight into the next sprint as new stories with a high priority.

Bugs as stories has some problems, with only a weak link back to the original story, you often end up having to group them in different ways, automating things like the fix version needing to be inherited from the original story and struggling to make sure they are all included in the right releases.

Bugs as stories also work better when you have people outside your development and test teams raising them (I like calling "bugs found by testing" "defects", whereas a "bug" is more likely to come from an end-user after you've released something with a bug in it), as the story approach for work not being generated by your scrum/development/design team is better.

Bugs as sub-tasks works better for Kanban and waterfall and others - you have a story, a bug is found the story is re-opened (or blocked from being closed until the sub-tasks are done - build testing into the workflow to keep it simple), so you keep working it until all the bugs are fixed.

There are merits in both ways to do it. There are other ways as well, but I don't see many of them that are not variations of the two above.

Finally, if you are doing testing in Jira, I'd strongly recommend a look at the testing Apps you can get to add to it - they can really help track and trace tests and the bugs they can spawn (I do work for Adaptavist who produce one of these tools, but this isn't a conversation for any sales-spiel on that subject, so I'll leave it as "you should look for testing tools in the marketplace, and evaluate them to see if they do what you need")

sudhir_utytrv

Nic thank you for your comments. This info is helpful.

thanks

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server