Agile Testing: A Practical Guide for Testers and Agile Teams

The call center staff reported an incident in their tracking system. They tried to solve the customer’s problem immediately. Often, that meant providing a work-around for a software defect. The call center report was closed, but a problem report in Remedy was then opened, and someone in the development team was sent an email. If the defect was accepted by the development team, a defect was entered into Bugzilla to be fixed.

There was no loop back to the problem issue to close it when the defect was finally fixed. We held several brainstorming sessions with all involved stakeholders to determine the best and easiest solution to that problem.

The problem statement to solve was, “How does the project team report back to the problem and change management folks to tell them when the bug was actually fixed?”

There were a couple of ways we could have solved the problem. One option was to reference the Remedy ticket in Bugzilla and put hooks into Remedy so that when we closed the Bugzilla defect, Remedy would detect it and close the Remedy ticket. Of course, some of the bugs were never addressed, which meant the Remedy tickets stayed open forever.

We actually found a better solution for the whole team, including the problem change folks. We brainstormed a lot of different ideas but decided that when a bug was opened in Bugzilla, we could close the Remedy ticket, because we realistically would never go back to the original complaint and tell the customer who reported it, or when the fix was done.

The change request that covered the release would automatically include all software fixes, so it followed the change management process as well.

—Janet

If your organization is using some kind of process model or quality standards management, educate yourself about it, and work with the appropriate specialists in your organization. Maintain the team’s focus on delivering high-quality software that provides real business value, and see how you can work within the model.

Process improvement models and frameworks emphasize discipline and conformance to process. Few software development methodologies require more discipline than agile development. Standards simply enable you to measure your progress toward your goal. Agile’s focus is on doing your best work and constantly improving. Agile development is compatible with achieving whatever standards you set for yourself or borrow from a process improvement measurement tool.

Separate your measurement goals and standards from your means to improve those measurements. Set goals, and know what metrics you need to measure success for areas that need improvement. Try using task cards for activities that provide the improvements in order to ensure they get the visibility they need.

Working with existing quality processes and models is one of the biggest cultural issues you may face as you transition to agile development. All of these changes are hard, but when your whole team gets involved, none are insurmountable.

Summary

In this chapter, we looked at traditional quality-oriented processes and how they can be adapted for an agile environment.

The right metrics can help you to make sure your team is on track to achieve its goals and provide a good return on your investment in them.

Metrics should be visible, providing necessary milestones upon which to make decisions.

The reasons to use a defect tracking system include for convenience, for use as a knowledge base, and for traceability.

Defect tracking systems are too often used as a communication tool, and entering and tracking unnecessary bugs can be considered wasteful.

All tools, including the DTS, need to be used by the whole team, so consider all perspectives when choosing a tool.

A test strategy is a long-term overall test approach that can be put in a static document; a test plan should be unique to the project.

Think about alternatives before blindly accepting the need for specific documents. For example, the agile approach to developing in small, incremental chunks, working closely together, might remove the need for formal traceability documents. Linking the source code control system comments to tests might be another way.

Traditional quality processes and process improvement models, such as SAS 70 audits and CMMI standards, can coexist with agile development and testing. Teams need to be open to thinking outside the box and work together to solve their problems.

Part III The Agile Testing Quadrants

Software quality has many dimensions, each requiring a different testing approach. How do we know all the different types of tests we need to do? How do we know when we’re “done” testing? Who does which tests and how? In this part, we explain how to use the Agile Testing Quadrants to make sure your team covers all needed categories of testing.