Professional Documents
Culture Documents
Whats Agile? Agile is more than a buzzword. It is a relentless focus on providing business value, usually by adopting one or more Agile methodologies such as Scrum or XP.
See the Agile Manifesto: http://www.agilemanifesto.org And the Agile Alliance: http://www.agilealliance.org
Extreme Programming (XP) Rigorous set of practices designed to keep both the code and team agile.
4
Agile Synthesized
Communication and collaboration Visible indicators Disciplined development practices Feedback Whole team thinking Short iterations Low overhead, high productivity
1. Compress the schedule 2. Toss out the documentation 3. Code up to the last minute
The organization may gain short term speed but at the cost of long term pain.
How Traditional Test Practices Evolved With great optimism and the best of intentions, The Project Plan is announced:
Analyze Design Code Test/Bug Fix
Release
Release
to team support
10
11
12
When creating test artifacts Minimize duplication. Thought exercise: if a feature were removed from your software, how many test artifacts would have to be updated? Use tools designed for change. Hint: if the vendor says stabilize the interface first, run away!
Planning Handoffs
Automation
Documentation
13
Automation
Handoffs
Unfortunately, this is common practice: Download a generic, standard, formal test plan template from the Internet. Fill in every section in the template even if you dont understand it and have to make stuff up. Kill the maximum possible number of trees by distributing copies to every team member. The result is a large and mostly irrelevant plan that must now be maintained. Yuck.
Documentation
Planning
14
Handoffs
Planning
15
Documentation
Planning
Informal
Whiteboards Sticky Notes Index Cards Wikis Databases Gantt/PERT Charts Polished Documents
Formal
Handoffs
Automation
16
Planning
Documentation
Handoffs
Automation
How Much Does Documentation Cost? Informal polling of 162 software testers from 65 companies revealed that most spend more than 33% of their time documenting tests.
# Testers Reporting
17
Planning
Capture the essence, not the details. Step-by-step instructions cost time without providing value (usually). Point to other project documents. If its in the user guide, requirements, specs, etc., leave it there. Centralize generic tests in a checklist. Try this: count the number of times you find a common condition, like invalid dates or null strings, in the test docs. More than once is too many.
18
Documentation Automation
Handoffs
Which would you rather maintain? Choose the Import option from the File menu. A dialog titled Import File appears. Navigate to \\x\y\z\long.dat and click Open. A dialog titled Importing appears with the current status, a progress bar, and a button labeled Cancel. Click on the Cancel button. Choose OK on the confirmation dialog. Verify that the import stops. Or: Start a long import. Cancel it in the middle. Verify it stops.
19
Documentation Automation
Handoffs
Planning
A Lightweight Example
Change Documentation Automation
Handoffs
Planning
20
Documentation
Hint: when people joke about signing the handoff form in blood, the signoff process is more about blame than about producing good software.
Automation
Handoffs
Planning
21
Integrate Testing
Testing is not a phase. Its a way of life. Agile teams are test infected. The question, How will we test it? is as important as How will we build it? Co-locate testers and programmers. But sitting side by side does not ensure communication. Track testing status and programming status all together. Show tests run-passed-failed together with features/stories done and left to do.
Change Documentation Automation
Handoffs
Planning
22
Handoffs
Planning
23
Documentation
Traditional test wisdom says we cant start testing a feature until its accessible from an external interface (like a GUI). But we dont have to wait. Test automation can facilitate manual exploration.
Automation
Handoffs
24
25
2.
3. 4.
27
28
Further Reading Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. Cockburn, A. (2004). Crystal Clear: A HumanPowered Methodology for Small Teams. AddisonWesley. Crispin, L., & House, T. (2002). Testing Extreme Programming. Addison-Wesley. Poppendieck, M. & Poppendieck, T. (2003). Lean Software Development. Addison-Wesley. Schwaber, K. & Beedle, M. (2001). Agile Software Development with SCRUM. Prentice Hall.
Copyright (c) 2004 - 2005, Quality Tree Software, Inc.
29
Acknowledgements Many thanks to early reviewers of the ideas presented here: Brian Marick, William Wake, Jonathan Kohl, Jeffrey Fredrick, Daniel Knierim, Marc Kellogg, Danny Faught, Ron Jeffries, Hubert Smits, Rob Mee, Sherry Erskine, Amy Jo Esser, Gunjan Doshi, Dave Liebreich, Janet Gregory, Chris McMahon
30