Interaction Patterns: Tester finds bug!

Consider the following scenario, which probably happens hundred of times every day: Tester finds a bug! That’s great, or really bad, depending on where you look at it, but that’s not the focus of this blog entry. We’re interested in what happens next.

In the less-optimized team, the following sequence, with some variations, may start happening:

1. Tester: Umm, something looks fishy…This might be a bug.
2. Tester: Trying again…yupp, the same thing! This must be a bug.
3. Tester: Let me check the requirements document before I write the ticket.
4. Tester navigates to the root of the version-controlled documentation folder.
5. Tester is savvy, so she gets the latest documentation from the repository. This takes a while. She takes a coffee break.
6. Tester comes back from the coffee break. Opens the requirements document in Microsoft Word and looks-up this particular piece. Locating the exact location in the use case document takes a while, because the document is long.
7. Tester: Argh, this requirement document is a joke! Will these guys ever get it right?
8. Tester: It really does not say much about this thing, so I am going to write the ticket anyway. At least someone will take a look at it.
9. Analyst (next morning): QC found a bug, let’s triage it so it gets assigned to someone quickly.
10. Dev Manager: OK, let’s assign it to Developer.
11. Developer (after a day, two): Umm, something looks fishy…This might not be a bug.
12. Developer: Let me check the requirements document.
13. Developer navigates to the root of the version-controlled documentation folder.
14. Developer is savvy, so he gets the latest documentation from the repository. This takes a while. He takes a coffee break.
15. Developer comes back from the coffee break. Opens the requirements document in Microsoft Word and looks-up this particular piece. Locating the exact location in the use case document takes a while, because the document is long.
16. Developer: Argh, this requirement document is a joke! Will these guys ever get it right?
17. Developer: OK, here it is - says nothing about this thing. So, it is not a bug.
18. Developer: I am going to reject it and add the comment “Coded per requirements”.
19. Tester (next morning): My bug got rejected!
20. Dev Manager: Can three of you get together and talk?
21. Tester, Developer, Analyst (analysts’ desk, the next day): Let’s open the document.
22. Analyst navigates to the root of the version-controlled documentation folder.
23. Analyst is savvy, so she gets the latest documentation from the repository. This takes a while. All take a coffee break.
24. Everybody come back from the coffee break. Open the requirements document in Microsoft Word and look-up this particular piece. Locating the exact location in the use case document takes a while, because the document is long.
25. Analyst: Is this the right version? I remember deleting these several lines.
26. Analyst: Let’s get version history. Yes, looks like it was updated six weeks ago. So, where are my changes?
27. Analyst: Oops, I forgot to export it from DOORS/ClearCase and check in to the version control system. What’s coded and tested is really not what the business needs right now.
28. Everybody: Rinse and repeat.

Does this ever happen in your project? I’ve seen it more often than I care to remember and despite that it seems trivial, changing behaviors takes time and perseverance.

What would a highly-effective team do in this situation? Let me attempt to construct an non-exhaustive list of things. This is just one way of achieving efficiency; there are probably infinite number of ways.

First, the team starts with a long-term vision and focus on people, practices and tools. Hire the best people, train them in cross-functional environments and create a reward structure which takes into account individual contributions in addition to team achievements.

Second, [over time] the team accumulated a list of practices and follows them.

Third, it uses tools that support the team practices.

So here is a version of the same sequence in a highly-efficient team, and somewhat shorter:

1. Tester: Umm, something looks fishy…This might be a bug.
2. Tester: Trying again…yupp, the same thing! This must be a bug.
3. Tester: Let me check the requirements WIKI page before I write the ticket.
4. Tester navigates to the root of team WIKI server. Performs a search and the requirements page comes-up first.
5. Tester: Himm, this requirement page has changed 134 times since last year. I wonder which one I am testing.
6. Tester performs another search, this time for the release notes. The search is based on the SCM label dropped to the QC environment. The release notes has an automatically-generated list of requirement numbers along with versions. Cool!
7. Tester: OK, so I am looking at the right version. Still, the requirement sounds ambiguous.
8. Tester chats with analyst in the hallway. Analyst stops by her desk and takes a read at the open WIKI page.
9. Analyst: Yes, this requirement stinks, I am sorry. Let’s edit it together here to add the clarification.
10. Analyst edits the page. Saves it in a new version with the comment: “Adding more clarity to BR:982. No coding required”. Analyst maks this as “Minor change”, so no new version of the page is created.
11. Tester: Thank you for the clarification. This is not a bug.

Now, does this happen in your project? Are there ways to optimize this even further? Probably yes.