Do Agile projects use abbreviated defect reporting?

Question

I'm accustomed to relatively rigid defect reporting, something like this.

Steps to reproduce:
1. Access customer manager for user Test01
2. Check "User must change password" and click Apply
3. Access login page
4. Enter user name and password
5. Click Login

Expected results:
6. Site displays user profile page (see use case 21.1.2)

Actual results:
6. Site displays error page (see attached screen shot)

I recently joined an Agile project where the defect reports look more like this:

Can't sign on with user Test01, see screenshots

In my many years of development experience, I've found that the longer defect reports serve numerous purposes, e.g. it succinctly communicated the precise problem and avoids any sort of judgmental language, and clearly represents the defect as a departure from a required behavior, rather than allowing the QA engineer to make up defects for behaviors that "seem" wrong.

Agile methodology de-emphasizes the importance of documentation. Instead we're encouraged to pick up the phone and talk to each other.

Is this a valid application of Agile principles? Or should defect reports be fairly verbose even when we're trying to be agile?

I think you answered your question within the question... *"Agile methodology de-emphasizes the importance of documentation. Instead we're encouraged to pick up the phone and talk to each other."* — Alex, Sep 23 '14 at 15:09
"rather than allowing the QA engineer to make up defects for behaviors that "seem" wrong". Sounds like the developers have written bad documentation if the QA engineer makes up defects ;-) This can also be avoided if you show him the things he needs to test and explain him what the exact behaviors are. He should not be sitting at the other end of the phone but in the same room as the rest of the development team. Agile doesn't de-emphasize the importance of documentation, it emphasizes the value of talking to each other (individuals and interactions). — user99561, Oct 05 '14 at 19:31

score 10 · Answer 1 · answered Sep 23 '14 at 15:39

If encouraging people to frequently interrupt each other just because of plain laziness is considered Agile, then I have to admit that my understanding of Agile is seriously broken.

A sufficient problem description is not a (potentially superfluous) product documentation, rather it is a distinct collection of all facts necessary to efficiently reproduce and solve the issue.

If the description in whatever form is sufficient, fine. If that's not the case, close it as "Not reproducible, reopen if new infomation becomes available" - with one exception: If you feel the need to investigate because of the potential risks uncovered by the issue, you may consider biting the bullet and follow-up. You don't want (e.g.) a security issue left unfixed just because of a poor description.

score 6 · Answer 2 · answered Sep 24 '14 at 08:36

"Agile" does not mean you have no rules and processes - just that you should try to get by with as little as possible (but no less, to paraphrase the Einstein quotation). The Agile Manifesto expresses this as "Individuals and interactions over processes and tools".

In your case that means you should discuss this with your colleagues. Explain the benefits you see in having more structured bug reports, and try to find a solution that everyone can work with.

Maybe some of your colleagues have good reasons for not wanting to require more structured reports (for example, not scaring off users who want to report bugs, or because they found that the structure never quite made sense) - or maybe they just never thought about it. You'll only find out by asking :-).

Greg Burghardt · Answer 3 · 2014-09-24T14:13:20.243

Bug reports from users always seem to follow this template:

I can't {action here} when I {another action here}

Or

When I {action here} it doesn't work

There's not much you can do about that. However, regardless of your development methodology, getting these kinds of bug reports from QA testers is absolutely unacceptable. When QA sends a bug report my way with that little information, I kick it back telling them to give me steps to reproduce and clearly state what went wrong and what should be happening.

If QA can only give you a bug report in one of the formats above, that means the QA tester may need some help from a developer to root out the problem, or if the tester is new to the project and not familiar with the business rules. This is acceptable, but not until after due diligence from the tester.

You can encourage users to give you more detailed bug reports, but know that you will get probably get little information. When that happens, have QA vet the bug to see if it can be reproduced, or contact the client and set up a walk through.

score 2 · Answer 4 · answered Sep 24 '14 at 13:15

It is important to remember that Agile is not a set of strict rules, but rather a mindset of process improvement. As Dave Thomas has famously pointed out, agile is an adjective, not a noun. By definition, you can't do agile, you can only be agile.

So how an agile team handles bug reports should be based on the most effective way that the team has discovered that helps deliver working software. This could be different for different teams depending on the context they work in. If the process you are using doesn't work for you, change it. If you see a way that it could be better, change it. (If it cannot be changed, you aren't agile)

The thing to do would be to find out why it is the way that it is. Other answers here have proposed possible explanations. Talk to your tech lead or your team lead and ask how they came to the current process. Make suggestions about how to improve the process.

score 1 · Answer 5 · answered Sep 24 '14 at 14:30

There are no rules in Agile that say you must have abbreviated bug reports -- the type of bug reports is controlled by whatever works best for your team or organization. If the abbreviated reports work for everyone, that's agile. If complex bug reports work best, that's agile too.

Agile is empowering the team to do whatever it is that lets them be the most productive, without being forced to adhere to a particular set of rules established by someone outside the team.

score 0 · Answer 6 · answered Sep 25 '14 at 00:05

Both of your examples might be perfectly agile. It all depends on your needs, your people, and the current phase of the development cycle. Generally I've seen QA teams use screen captures and recording as a support tool to complement the bug report. Why? According to QA people, getting good screen captures and recordings is not as easy as just typing. Also there are some steps that are less prone to be represented as a screen capture, like changing configurations by command line; developers will love that you typed that, so they can just c&p it; they will hate you if you only attached a screen capture :)

Do Agile projects use abbreviated defect reporting?

6 Answers6