Abstract:Agile development hit mainstream recognition a long time ago. Yet there is often uncertainty and turmoil around what "agile development" means, in theory and in practice, and the place of testing within it. The confusion affects agile projects and the people in them.
There have been some discussion points, such as Mike Cohn’s Agile Testing Pyramid and Marick, Crisipin and Gregory’s Agile Testing Quadrants, and many people have found them helpful. Yet James Bach and Michael Bolton, authors of Rapid Software Testing, still hear testers expressing a good deal of pain over the role of the tester and the structures of testing activity in Agile projects.
Is there really such a thing as “Agile Testing”, or does testing remain testing while "agile" is context? Building on what has gone before, Michael Bolton will offer a refactoring of testing in agile contexts, with a refactored set of Agile Testing Quadrants. He'll use the lens of Rapid Software Testing—an agile (but not necessarily Agile) approach to testing that focuses on the mindset, skill set, and role of the tester. Michael will show how Agile projects can—and should—be infused with testing that helps to identify, defend, and maximize the value of the product while reducing the costs of development.
Learning Outcomes:- Attendees will learn about a set of frames for looking at test activity throughout the project: Intention (design-focused activity by which we discover what the customer really wants); Discipline (shallow testing that can help us discover if what we just did is reasonably close to what we intend to do); Preparation (advocating to make the product reasonably testable, and organizing the project and systems to facilitate testing work); and Realization (deep testing that can help us discover subtle, rare, or emergent problems that threaten the value of the product).