What do you mean, don't submit bugs?

Of all of my "aha!" moments in transitioning from a waterfall-style QA person to an agile tester, the one I am about to talk about is *definitely* in the top 3. Top 5, most .... *Definitely* top 10. :)

I have to give my credit to Janet Gregory, yet again ... during her presentation at STAREast that I named in my last post. This one, in particular, hit me personally, rather than being a suggestion for the whole team.

Janet talked about how as an agile tester, the "Quality Police" mindset must be avoided. I have to admit, I am *really* guilty of playing "quality police". *REALLY* guilty .... However, I was *really shocked* when she said that one of the indicators that you may be playing "quality police" is that you insist that all bugs go into a bug tracking system.

"Well, DUUUUUUUH," I thought, "OF COURSE all bugs go into the bug tracking system!"

(pause)

Wait. What?

As this discussion went on, I learned that there was a practice that I not only had never thought of, but actually made sense! It went something like this: When testing in the scope of a user story inside a sprint, DON'T SUBMIT BUGS. Just go talk to the developer and have him fix it!

I brought this idea back to my team. It was easy to sell this one ... I was able to play the humble one, and show them Janet's slide that shows the indicators for "quality police". We all had a big laugh while the list was read ... describing me, just about to a tee.

The amazing part, however, was that within hours, I could hear testers going to developers and talking about things they found, and I could hear developers yelling, "Hey Sally! I checked in that change. Get latest and let me know." It was almost like this team was waiting for exactly this kind of idea.

What we decided follows roughly this pattern: If a tester is testing a user story card within the scope of a sprint and finds a small problem that can be fixed easily, they just go talk to the developer (maybe send an email ... ). Bugs are submitted if issues are found relating to work done in a previous sprint, or if an issue is so big that it can't easily be fixed within the scope of the current sprint, or if we hear about issues from our customers (our product owners or beta users, for example).

I monitor the bug list and watch for developer activity during a sprint that relates to issues in the bug list. If I see that a developer is working in a certain section of code, I ask if he can look into the related issue. In this way, I still get to play quality police *a little* ....

Benefits that we see from this process:

• fewer bugs (which means less of everyone's time reviewing bugs) !!
• more developer/tester interaction ... better relationships
• better tester insight into developer processes (they talk about where problems are in the code)
• less email traffic
• cards marked as 'done' earlier

Pitfalls:

• ? I haven't yet seen any direct pitfalls .... the one concern I have is not being able to analyze issues for patterns. I have in the past, seen a bug crop up several times, and being able to review previous discussions and/or fixes can help reduce troubleshooting/fixing time. Instinct tells me that I can look through checkin comments just as easily ..... but this is an edge case, nonetheless ......

Personally, I was amazed at how willing I was to give up the "quality police" mindset. I simply had not realized how much that mindset was interfering with the team integration, and just how much closer testers and developers were when this barrier was removed. I realized that in order to be a better agile tester, I had to remove my own barriers. This was a big one, and I have been watching, first-hand, just how much better the team operates with this one removed.