With a hint of HP Quality Center Agile development and functional testing: friend or foe? Tom Vercauteren, June 26th, 2009

1.User stories 2.Sprint backlog 3.Daily stand-up 4.Sprint burn down 5.Other ideas

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 3 User stories We test “per User Story”, and these stories are “bundled” in Sprints: In HP Quality Center

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 4 User stories Sprints contain a number of Stories: In HP Quality Center

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 5 User stories When a Story is being developed, we write tests: In HP Quality Center

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 6 User stories When a Story is developed, we execute tests: In HP Quality Center

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 7 User stories What the customer tells you: “As a customer I want to open a document so that I can view it.” What comes up along the Sprint: -We only want to view PDF files. -Large files should still be opened within 5 seconds. -I want to open the file in my browser, or save it to my hard disk. This information is usually “found” in the daily stand-up meeting, and told to the developer. It is almost never formally captured. It might be forgotten in the next sprint, or during testing. And acceptance criteria

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 8 User stories And acceptance criteria According to Scrum, we should add “acceptance criteria”: After the sprint, add them to the functional documentation! US Document viewer 2 story points US Document viewer 2 story points Only PDF Open in IE Save to disk Open in IE Save to disk File of 10 MB: < 5 sec. File of 10 MB: < 5 sec.

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 9 User stories And acceptance criteria Who? -Anyone who thinks of them / discovers them. Why? -Don’t forget them during development or testing. -Might even end up in documentation / user manual. What? -Any functional or technical “need to know” item. When? -During daily stand-up -Any time!

1.User stories 2.Sprint backlog 3.Daily stand-up 4.Sprint burn down 5.Other ideas

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 11 Sprint backlog – Sprint planning And functional testing US Document viewer 2 story points US Document viewer 2 story points Sprint backlog HP Quality Center

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 12 Sprint backlog – Sprint planning And functional testing Sprint backlog: -Contains Spikes -Contains Technical User Stories (e.g. “setup acceptance environment”, “write manual”, …) -Contains Functional User Stories HP Quality Center -Does not contain Spikes -Does not contain Technical User Stories -Contains a set of tests for every Functional User Story -Contains non-functional Acceptance Criteria (e.g. “UI should work on 7 different browsers)

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 13 Sprint backlog – Test preparation And functional testing US Document viewer 2 story points US Document viewer 2 story points Task Task Task … Task … 25504

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 14 Sprint backlog – Test execution And functional testing US Document viewer 2 story points US Document viewer 2 story points Testable Test this Test this OR Use “testable” for shared testers (or “finished” for Spikes) Use tasks for dedicated testers Note: test work should be subject to “planning poker” (even if you use “testable”)

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 15 Sprint backlog – Test execution And functional testing US Importer Validation 2 story points US Importer Validation 2 story points Testable This may include regression tests.

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 16 Sprint backlog – Defect tracking And functional testing

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 17 Sprint backlog – Defect tracking And functional testing US Document viewer 2 story points US Document viewer 2 story points 2609 No error msg. on import of DOC No error msg. on import of DOC Testable Decision make by team: -Fix in this Sprint -Add to Product Backlog, for later fixing -“not a bug”

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 18 Sprint backlog – Re-testing And functional testing US Document viewer 2 story points US Document viewer 2 story points Testable Developer updates HPQC: -Fixed in what release? - What was the problem?

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 19 Sprint backlog – When testing is “done” And functional testing US Document viewer 2 story points US Document viewer 2 story points Q.C. Passed Q.C. Passed “Q.C. passed” means that no significant problems were found (given the limited time the tester spent on this story)

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 20 Sprint backlog – When testing is “late” Bugs are found “during the next sprint” Bugs previous sprint Create a dummy User Story. As this story will contain bugs that belong to the previous sprint, this has high business value No error msg. on import of DOC No error msg. on import of DOC 25504

1.User stories 2.Sprint backlog 3.Daily stand-up 4.Sprint burn down 5.Other ideas

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 22 Daily stand-up And the tester The tester should be present at the daily stand-up meetings. If you share a tester between projects, he should still be present at least twice a week. -Best practice: “all shared team members (tester, customer rep., project manager, …) attend our daily scrum at least on ” -Best practice: “As a shared team member, I always inform the team of when I’ll (not) attend the daily scrum.”

1.User stories 2.Sprint backlog 3.Daily stand-up 4.Sprint burn down 5.Other ideas

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 24 Sprint burn down And defects found US-1 testable Defects found US-1 “Q.C. passed” US-2 testable Defects found Add 15% story time for bug fixes: add “blanc” tasks

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 25 Sprint burn down And defects found The last user story can be tested on the last day of the Sprint -Testing is probably not done at the end of the Sprint -We end up with bugs that are not fixed in this Sprint. Can we go LIVE with this situation?

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 26 Sprint burn down And defects found Solution: a Hardening Sprint A short Sprint No new user stories Only bug fixes and re-testing Perhaps time to finish documentation? Sprint 4 (3 User stories) Sprint 5 (2 User stories) Go LIVE

1.User stories 2.Sprint backlog 3.Daily stand-up 4.Sprint burn down 5.Other ideas

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 28 Other ideas? Your opinion matters US Document viewer 2 story points US Document viewer 2 story points Q.C. Passed Q.C. Passed Demo versus Acceptance testing? -A demo is not enough as “acceptance test”! -The user representative should do more extensive testing (preferably the day before the Sprint Review) -Create a “finished user story” list, and add “user acceptance testing passed” notes. U.A.T. Passed U.A.T. Passed 25504

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 29 Other ideas? Your opinion matters! User Stories that do not deliver a UI (e.g. web services) should we always deliver a “test app” for testing purposes. Definition of done: -Task: tested by developer (unit & integration tests) -User story: functionally tested, no significant defects left -Defect: resolved by developer, re-tested and closed by tester …

-User stories -Sprint backlog -Daily stand- up -Sprint burn down -Other ideas 30 Other ideas? Your opinion matters! What did I forget? What was unclear? … With special thanks to Syed Rayhan, who reviewed this presentation. Take a look at his presentation on ScrumAlliance.org: “A practical guide to implementing Agile QA process on Scrum Projects”