How To Fit Testing Into The Iteration
14 likes6,696 views
The document outlines how testing is integrated into agile iterations through user stories, acceptance criteria, and collaboration between team members. It emphasizes that quality is 'baked in' throughout the development process rather than checked at the end. Agile teams focus on continuous improvement, prioritizing value-driven delivery with minimal defect management overhead.
How To Fit Testing Into The Iteration
- 1. How to Fit Testing in the Iteration www.rallydev.com 1 © 2009 Rally Software Development, Inc.
- 2. The Grains Have Been Changed… • Fully tested, working code every 1-4 week iteration. • New teams often wonder how testing can be squeezed into that timeframe • If anything, there is more time devoted to testing on an Agile project. • What changes is the size or grain of what’s tested. The most common “System Under Test” (SUT) is a user story – typically the result of 1 to 3 days of work. In this presentation, we’ll walk through a typical iteration, highlighting test activities and showing how Quality is “Baked In” as part of the process vs. “Tested In” at the end. (Graphics adopted from Naresh Jain, Licensed under Creative Commons) www.rallydev.com 2 © 2009 Rally Software Development, Inc.
- 3. Testing in the Iteration Starts with the User Story www.rallydev.com 3 © 2009 Rally Software Development, Inc.
- 4. The User Story Describes What the System Should Do • During iteration planning, the team agrees on a set of User Stories to be delivered. A User Story describes what the system should do, in a way that emphasizes value to a user. • Example: Review Items in Shopping Cart As a shopper, I want to see a list of items, prices and delivery dates as I checkout, Rally allows teams to define, prioritize, schedule, track and report on User Stories, so that I know what I ordered, when I get it and Tasks, Defects, Test how much it costs. Cases and Test Results www.rallydev.com 4 © 2009 Rally Software Development, Inc.
- 5. Every User Story has Acceptance Criteria • At the start of an Agile iteration, the product owner reviews the prioritized user stories. • Testers ask questions that elicit examples and clarification. • User stories are given Acceptance Criteria (AC). AC are business oriented tests that let us know if the implementation meets Product Owner expectations. • Acceptance Criteria are written so that: • The Product Owner can verify that the story was implemented as intended • Developers and Testers know when they are done www.rallydev.com 5 © 2009 Rally Software Development, Inc.
- 6. Testers help PO’s clarify with Examples and Tests • The Product Owner (PO) whiteboards an example… • The Team has questions... How do we display out of stock items? If a shopper applies a promo code, should we show list and discounted prices? What about shipping charges? Is there really a book titled “American Nerd”?, etc. The PO answers and clarifications are made to the AC. This process of “just-in-time” elaboration continues throughout the iteration. As questions arise during the iteration, the PO is available for team members to ask for clarification. • The AC does not cover boundary conditions. These will be addressed by unit and exploratory testing. We’re primarily concerned with specifying the business value that should be delivered. The test serves a requirements and design role. Testing and Development become one process. The whole team owns quality. www.rallydev.com 6 © 2009 Rally Software Development, Inc.
- 7. User Stories Break Down into Tasks Test Tasks are Included • Iteration planning continues as the team breaks the user story (the what) into tasks (the how) and estimates effort • Testers fully participate in estimating effort by adding test tasks to the User Story breakdown. For example… Rally makes it easy for teams to collaborate and see story and task status Stories move from Backlog (B), to Defined (D), to In-Progress (P) to Complete (C) to Accepted (A) www.rallydev.com 7 © 2009 Rally Software Development, Inc.
- 8. Testing and Coding are One Process In the Iteration, Testing and Coding occur at the same time • A programmer picks the first task • The tester picks the first test task. • Typical test tasks include defining test data, designing test approaches, evaluating risk, etc. • Testers, Developers and Product Owners continue to clarify story requirements, brainstorm testability approaches and collaborate as a team. Product Owner, Developer and Tester work together towards their shared objective: A High Quality product that Delivers Business Value www.rallydev.com 8 © 2009 Rally Software Development, Inc.
- 9. Agile Developers are Responsible for Unit Testing • Unit tests are written by programmers, in the same language they develop in, usually using one of the popular xUnit frameworks. • These tests take the smallest piece of testable code, isolate it from the rest of the system, and determine if the results are as expected. • Since unit tests isolate the code under test, they remain stable over time, with very low Total Cost of Ownership (TCO) www.rallydev.com 9 © 2009 Rally Software Development, Inc.
- 10. Unit Testing frees Testers to Automate Acceptance Tests and Do Exploratory Testing • With Unit Testing, Testers get much higher quality code to start with • While programmers are coding, testers are preparing Acceptance Tests • When dev tasks complete, developer and tester walk through different scenarios for the story • Tester and Developer collaborate until the Acceptance Test is “Green” • Exploratory Testing begins as soon as the story is coded • Both tester and programmer have the story at the top of their mind or in context. This dramatically boosts productivity. www.rallydev.com 10 © 2009 Rally Software Development, Inc.
- 11. The Product Owner Accepts the Fully Tested Story • Teams commit to delivering a set of User Stories with an Iteration • Each User Story must be accepted by the Product Owner • The Product Owner reviews the implementation and either accepts the story or requests changes. • The Team also agrees on a general “Definition of Done” for stories. Fully tested and defect-free are part of the criteria. • Testing can never “fall behind” coding because no stories are accepted without being fully tested. Quality gets baked into the process. www.rallydev.com 11 © 2009 Rally Software Development, Inc.
- 12. Non-Functional Requirements are Scheduled as User Stories in the Iteration • Performance, Load Testing, Security and other Non-Functional Requirements are Scheduled in the Iteration • User stories are used to capture these requirements • As a shopper, I want all of my checkout pages to display in less than 2 seconds so that I don’t get frustrated and cancel my order • As a shopper, I want to be able to use Firefox 3.0+, MSIE 6.0+, Safari 3.2+, or Opera 9.6+, or Chrome 1.0+ so that I’ll have a supported browser 99% of the time. • As a shopper, I want my credit card number protected from identity theft, so that I don’t experience financial ruin and start a class-action suit against you • Testing may be done by a specialty team • If this is the case, the tester within the team acts as a proxy for the specialist group • Testing begins much earlier in the development cycle. The team can respond to performance, security and usability issues while there’s time to address them. www.rallydev.com 12 © 2009 Rally Software Development, Inc.
- 13. How Does Defect Management Change? The High Defect Counts on Traditional Projects Add Weight • Traditional projects use the Defect Tracking System (DTS) for workflow, with complex rule engines for routing and signoffs • Results are heavy process burdens, high management effort and delay • The DTS becomes a hidden “backlog” of work, and the project end game is defect-driven www.rallydev.com 13 © 2009 Rally Software Development, Inc.
- 14. Agile Teams are “Value-Driven” – Not “Defect-Driven” • Stories are the unit of value and tests indicate when that value is complete. • Defects are killed on arrival or scheduled alongside of new features to be prioritized by the product owner. • Continuous testing and integration combine with short iterations for tiny defect counts, typically dozens, with little management burden and team overhead. • The team resolves failures immediately. Potentially shippable code is the goal. Complex defect workflows are replaced with the simplicity of Pass/Fail www.rallydev.com 14 © 2009 Rally Software Development, Inc.
- 15. Test Impediments are Addressed in the Retrospective • Every Agile iteration has a retrospective at the close of an iteration. • In the retrospective, the team looks back at the iteration, notes facts and feelings, generates insights and decides what to do about them. • Retrospectives are great tools for improving testability and raising test issues • For example, • We need a Virtual PC image for Safari browser testing • John’s shopping cart FitNesse Adapter makes it easier to write tests, we should look at more domain specific approaches. • The GUI smoke test was hard to write without unique IDs Agile Teams focus on continual improvement, Building quality in is faster than inspecting defects out www.rallydev.com 15 © 2009 Rally Software Development, Inc.
- 16. Summary and Next Steps Summary Next Steps • Agile teams “Bake Quality In” • Explore the Implementing Agile Teams , making testing, early Agile Test & Engineering Practices, and feedback and continuous Rally JumpStart Service Offerings improvement part of the process • View the next presentation, • Coding and Testing are One “Build and Test Automation” to see – Coding doesn’t start w/o how Agile Teams shorten feedback Acceptance Criteria loops and boost productivity – User Stories are not accepted unless they are tested + defect free • Review the Related Materials for • Agile teams spend as much or more time on guides, sample meeting agendas and testing as traditional teams, but the grain of additional resources what’s tested is smaller. www.rallydev.com 16 © 2009 Rally Software Development, Inc.