Crispin, Lisa - Agile Testing - A Practical Guide for Testers and Agile Teams

The team worked out a compromise that worked for everyone. Bugs that were found during pair testing with the programmers were not recorded, because they were fixed right away. All others were logged in the DTS. Bugs that needed to be fixed in the current iteration were recorded on pink cards with the summary and bug number and then put on the story board. All others became part of the product backlog.

The programmers could look at details in the system but also asked testers for more information, if required. Because the issues were on the story board, they became part of the daily stand-ups and discussions. When a bug was fixed, the programmers wrote the fix and any extra information on the back of the card. They put a blue sticker on the card so the testers knew it was ready for testing. A green sticker meant it had been verified as fixed, and a red sticker meant it wasn’t fixed and needed more work. Of course, there were lots of conversations between the testers and the programmers. James, one of the programmers, and I had a lot of fun with one bug that just wouldn’t stay fixed. By the end, the card looked like it had a caterpillar on it—blue, red, blue, red, blue, and finally green. We were all quite excited when that bug was squashed.

The testers closed bugs and did most of the administration, because the DTS was their requirement. After a while, the programmers started entering what they fixed into the defect-tracking system because it was easier than writing on the card. The team still continued to use the cards because of the visibility. It was easy to see at a glance how many outstanding bugs there were in the iteration or on the backlog.

—Janet

This approach worked for this team because there was a lot of discipline in the team, and most new bugs were fixed in the iteration if they were part of the new or changed functionality. The only bugs that went into the backlog were legacy bugs that were deemed low risk.

Start Simple

We suggest using as simple a system as possible and applying complexity as required. Code produced test-first is, in our experience, fairly free of bugs by the time it’s checked in. If you’re finding a lot of bugs in new code, your team needs to figure out why, and take action. Try to shorten the cycle of coding, integrating and testing so that programmers get immediate feedback about code quality. Perhaps some buggy section of legacy code needs to be redesigned before it mires your team in technical debt. Maybe you need to work more closely with the business experts to understand the desired functionality.

Another idea might be to create an ongoing “start, stop, continue” list so that you can remember some of the issues during the iteration retrospective.

More on retrospectives in Chapter 19, “Wrap Up the Iteration.”

Facilitate Communication

The daily stand-up helps teams maintain the close communication they need. Everyone on the team learns the current status of tasks and stories, and can help each other with obstacles. Often, hearing programmers describe tasks they’re working on provides a clue that they may have misunderstood the customer’s requirements. That signals the need for a group discussion after the stand-up. If a tester needs help with a testing issue that’s come up, she might ask the team to stay after the stand-up to talk about it. Missed tasks are often identified during stand-ups, and new cards can be written on the spot.

The stand-up is a good time to look at progress. Use big, visible charts such as story boards, burndown charts, and other visual cues to help keep focus and know your status. If the end of the iteration is drawing near, and coding on a story seems “stuck,” raise a red flag and ask the team what can be done about it. Perhaps some pairing or extra help will get things going. Lisa has often noted when there’s a lot of testing left to do and time is running out. She asks for help to pick up the slack. The whole team focuses on what needs to be done to complete each story and talks about the best approach.

When teams use an electronic medium for keeping track of stories, there is a tendency to forget the story board. Janet finds that having both may seem like a duplication of effort, but the visibility of progress to the team far outweighs the extra overhead of writing up the task cards and moving them as they are completed. Having the story board gives your team focus during the stand-ups or when you are talking to someone outside the team about your progress.

Testers Facilitate Communication

Testers can help keep the iteration progressing smoothly by helping make sure everyone is communicating enough. Talk to programmers when they start working on a story, and make sure they understand it. Lisa finds that she can write all of the tests and examples she wants on the team wiki, but if nobody bothers to read them, they don’t help. When in doubt, she goes over requirements and tests with the programmer who picks up the task cards.

Programmers will always have questions as they develop a story, even if they understand the business and the story well. It’s best if a customer is available to answer questions, because that is the most direct communication. Testers shouldn’t get in the way of that; however, we’ve observed that business experts sometimes have trouble explaining a requirement, or a programmer simply gets the wrong idea and can’t get on the same page with the customer. The Power of Three applies here. Testers can help customers and programmers find a common language.

A Little Friendly Competition

Gerard Meszaros, well-known agile coach and author of xUnit Test Patterns [2007], shared this story about a team he was working with and how a game solved a communication issue.

We were having trouble getting the developers to talk to the business people about their assumptions. When they did talk, the tester often got left out of the loop. The tester would sometimes discuss something with the business but never pass it on to the developer. Our project manager, Janice, decided to try to change the behavior through friendly competition.

All of the developers were given blue poker chips with a “D” written on them. All of the testers got a red chip with a “T” on them, and the business people got yellow chips with a “B” on them. Whenever someone met with a counterpart from another area, he or she could exchange one chip with each person. The goal was to get the most complete sets of chips: T-B-D. The winner got a custom-made T-B-D trophy decorated with the three kinds of chips. The end result was that everyone was much keener to meet with each other because they would get more chips!

Find creative ways to get the business experts and programmers to talk and agree upon requirements. If a poker chip game gets them talking, embrace it.

Facilitating communication usually involves drawing on a whiteboard, mocking up interfaces, listing other areas that might be affected, or working through real examples. Whenever communication appears to reach a dead end, or confusion is rampant, ask for a new example and focus on that.

Lisa’s Story

When retirement plan participants want to withdraw money from their accounts, many complex vesting rules and government regulations come into play. It gets worse if the participant has withdrawn money in the past. Working on a story to calculate a participant’s vested balance, my team members all had different ideas on the correct algorithm, even though the product owner had worked through several examples at the beginning of the iteration. My fellow tester, Mike, asked the product owner to work through a new example, and several programmers and testers joined the session. It took a couple of rather tortuous hours of writing numbers and flowcharts on a whiteboard, but eventually they arrived at the correct formula, and everyone was on the same page.