I noticed one of our development teams was creating new Jira Issues for each bug found during the development cycle. IMO, this is an antipattern.
These are the problems it can create, that I can think of:
- New Jira Issues (bug reports) are creating unneccessry admin work for the whole team.
- We see these bug reports cluttering an Agile board.
- They may have to get prioritized.
- We have to track them, they have to get assigned, change statuses, get linked, maybe even estimated.
- They take time to create.
- They may cause us to communicate via text rather than conversation.
- Bug reports mislead lazy people into tracking progress, quality, or team performance by counting bugs.
- It leads to confusion about how to manage the User Story. If the User Story is done except for the open bug reports, can we mark the User Story “Done”? Or do we need to keep the User Story open until the logged bugs get fixed…”Why is this User Story still in progress? Oh yeah, it’s because of those linked logged bugs”.
- It’s an indication our acceptance criteria is inadequete. That is to say, if the acceptance criteria in the User Story is not met, we wouldn’t have to log a bug report. We would merely NOT mark the Story “Done”.
- Bug reports may give us an excuse not to fix all bugs…”let’s fix it next Sprint”, “let’s put it on the Product Backlog and fix it some other day”…which means never.
- It’s probably a sign the team is breaking development into a coding phase and a testing phase. Instead, we really want the testing and programming to take place in one phase...development.
- It probably means the programmer is considering their code “done”, throwing it over the wall to a tester, and moving on to a different Story. This misleads us on progress. Untested is as good as nothing.
If the bug is an escape, if it occurs in production. It’s probably a good idea to log it.
13 comments:
Subscribe to:
Post Comments (Atom)
RSS
These seem like good reasons. The first question that comes to mind is, what do you do about bugs/issues/problems/whatever-your-preferred-label-is? How do you keep track of them, if they can't be fixed (or shouldn't) be fixed right away?
Hi Matt. Give us an example of a bug that shouldn't be fixed right away or can't be. If that's the case, I guess it's okay to log it.
Consider the following scenario: The project has a hard deadline, and a bug is discovered that will require more time to fix than is available before that deadline. Development resources are constrained (ie. No late night/weekend work). Seems to me this might fall under the "can't" category. As for "shouldn't", I can't think of a good example at the moment.
I have a follow-up question: in your situation, how do you communicate issues to your dev team? Even if they sit right next to you, they may not be willing/able to interrupt their work immediately to look at the bug you've discovered, so there probably needs to be some way of logging the information for later review.
I get what you're saying, good reasons etc... but I can't help but feel as though logging a bug as you find it makes sense, instead of getting distracted (context switching) by trying to fix it there and then.
If it's not going to be fixed immediately it needs to be captured. Why not capture it in the same tool that you use to manage stories?
Genuinely interested to hear alternatives to this.
Cheers,
Ben
Hi Eric,
I agree with your opinion. To be more precise:
During feature development, it's more easy to leave comments in user story or to pair with developers. Then fixing and checking fixed bug immediately.
After new features are checked (after acceptance tests pass and PO's approve) and going to be integrated. If some issues related to new developed feature occur, it's time to open a but ticket.
So before integration, no ticket. After or during integration, then yes "ticket is coming".
Thanks for responding, Matt.
First, your scenario of a discovered bug without time to fix, burned out team, fixed deadline: Since most dev teams use Scrum, I'll assume Scrum. If we have an open bug, we probably didn't meet our "Done" definition, so we should carry that Story into the next Sprint. If that's not an option b/c we have a release date to make, we can log the bug and put it in the release notes.
Your other question is easier: My teams first use verbal. If the bug can't be fixed immediately, a comment on the User Story about the bug would work. This could be a new Acceptance Criteria or a Comment (e.g., Jira). But even email would probably be better than logging a bug report.
benbenbenbenben,
Think about this...the context switching problem occurs when we do log the bug. We are saying, "go ahead and do something else, I'll log it". The point of NOT logging it, and fixing it now, is to prevent context switching; the programmer should not have switched context in the first place because they aren't done. The programmer does some coding on UserStoryA, then asks the tester to look at it, as the programmer keeps working. If you haven't figured out how to code/test at the same time, you can just have the programmer wait for Tester feedback before starting UserStoryB. Or better yet, they can help test. Both Programmer and Tester should remain within the same context until their done. Then they should, together, switch the context. Get it?
Kevin, are you sure? I might be out of touch with the process you describe. Do you see integration testing as a phase? I usually don't. I think part of Feature development is making sure that Feature integrates.
How does this heuristic grab you? We only want to log a bug if we need to count it as part of a metric. And to my mind, the only bugs we want to count are "escapes".
I agree and especially if you are talking about the Dev environment (which I think you are) I would not agree with this if it were for a non-prod testing environment.
Developers should be working from tickets with precise requirements and acceptance criteria. It works or it doesn't...no need to log another ticket to say it's not working....
My question is what to do when there are missing requirements and the user fails the test due to missing requirements?
Options:
1.) A new ticket will be logged as a bug
2.) The new requirements are added to the current ticket (scope creep in my opinion)
3.) Log a new ticket to be prioritized to the back log for another sprint
Hi Anonymous, nice question. If there are missing requirements and the user fails the test due to missing requirements, I like your option #2. I think high performing teams know there is always a difference between the requirements and the requirement document. The actual full requirements are seldom known in advance. High performing teams account for this in their planning.
Hi Eric,
I am agree with your opinions.
A case where I create a ticket is for team's dependances.
Unfortunately, if bug depend an other dev team, for me it's easier to create a specific ticket. The other dev team need a specific context not just usert story specific.
Eric,
I liked the blog post regarding Jira. We have just recently within the last year switched over to using Jira. While there is definitely administrative overhead, I find that the way we have it set up for testing our next release saves both the testers and developers time. We have a project up set up specifically for testing our new release along with a project for our production release. When we start manually testing the new release that is on our development server we log the tickets under the testing project. This allows us to report fewer duplicates. We use Jing to share images or screen casts for each bug and send that with the ticket. This allows a developer to see what we were doing during the test, smaller bugs can be solved with less discussion, leaving more time for us to discuss bugs that are more complicated. On average though it is still a lot of overhead for administrative tasks.
Great post!
Fully agree and talk also in my own blog:
http://testeuragile.blogspot.fr/2016/06/defect-management-on-agile.html
Open a defect in agile is clearly an antipattern
Thanks for this article