Track: Agile Testing
One of the primary issues encountered when managing agile QA transformations has been getting people to do “just enough” test documentation to get started testing. To help address this issue, the speaker has taken to using Google”s “ACC” (Attributes, Components, Capabilities) test planning model as a guide for initial test planning. In this session he will present the problem, the model, and guide the class through planning testing on a project they”ve never seen before.
The Problem (10 minutes):
- “Just enough” documentation principles.
- Getting started testing without requirements or specifications
The Presentation (10 minutes):
- ACC explained.
- Walk through of the elements.
- Example Practicum Intro (15 minutes).
- Presentation of the software solution.
“Sprint kickoff” meeting Group Sessions (20 minutes):
- Breakout into groups of no more than four.
- Teams to get different user stories to test (hopefully to minimize “cross pollination”)
Begin test planning using ACC model Presentation/Review (15 minutes):
- Teams present their test planning.
- Gather group feedback.
- See if “next steps” are immediately apparent.
Questions/Wrap Up (5 minutes)
- Discussion of “just enough documentation” agile model.
- Introduction to Google”s ACC model (http://code.google.com/p/test-analytics/wiki/AccExplained) with use cases.
- Guided walk-through on using the ACC model to get testing earlier.
- Practical session using the model with coaching and feedback.
Please Note: The presentations are intended for attendees only. The presentations page is password protected – contact firstname.lastname@example.org for verification of attendance and the password to access the presentation.
Curtis Stuehrenberg – Trail Boss, Cowboy Testing
Curtis Stuehrenberg is a classically trained baritone and unsuccessful stage actor who stumbled into software testing when a friend pulled him, kicking and screaming, onto a project at Microsoft that would one day become Secure Business Server. The team wisely shunted him into the build and test lab where they assumed he would do the least harm. They were fortunately mistaken. Soon he was stalking the halls, causing fear and anger in developers and architects alike for having the effrontery to break “his” builds. Thirteen years later, he has mellowed somewhat and enjoys a challenging, rewarding, and at times successful career helping companies and teams walk the fine wire between craftsmanship and value. In what passes for his free time, he writes a little, leads the odd discussion, and argues passionately about things others often find vaguely interesting.