1 / 30

Agile development and functional testing: friend or foe?

Agile development and functional testing: friend or foe?. With a hint of HP Quality Center. Tom Vercauteren, June 26th, 2009. User stories Sprint backlog Daily stand-up Sprint burn down Other ideas. User stories. In HP Quality Center.

nichelle-brown
Télécharger la présentation

Agile development and functional testing: friend or foe?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. User stories • Sprint backlog • Daily stand-up • Sprint burn down • Other ideas

  3. User stories In HP Quality Center • We test “per User Story”, and these stories are “bundled” in Sprints:

  4. User stories In HP Quality Center • Sprints contain a number of Stories:

  5. User stories In HP Quality Center • When a Story is being developed, we write tests:

  6. User stories In HP Quality Center • When a Story is developed, we execute tests:

  7. User stories And acceptance criteria • 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.

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

  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!

  10. User stories • Sprint backlog • Daily stand-up • Sprint burn down • Other ideas

  11. Sprint backlog – Sprint planning And functional testing US-25504 Document viewer 2 story points Sprint backlog HP Quality Center

  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)

  13. Sprint backlog – Test preparation And functional testing US-25504 Document viewer 2 story points Task … 25504 Task 1 25504

  14. Sprint backlog – Test execution And functional testing US-25504 Document viewer 2 story points Test this. 25504 • 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”) OR Testable

  15. Sprint backlog – Test execution And functional testing • This may include regression tests. US-25565 Importer Validation 2 story points Testable

  16. Sprint backlog – Defect tracking And functional testing

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

  18. Sprint backlog – Re-testing And functional testing US-25504 Document viewer 2 story points Testable • Developer updates HPQC: • Fixed in what release? • What was the problem?

  19. Sprint backlog – When testing is “done” And functional testing • “Q.C. passed” means that no significant problems were found (given the limited time the tester spent on this story) US-25504 Document viewer 2 story points Q.C. Passed 25504

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

  21. 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 <weekday>” • Best practice: “As a shared team member, I always inform the team of when I’ll (not) attend the daily scrum.”

  23. 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 Add 15% story time for bug fixes: add “blanc” tasks Defects found

  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?

  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

  27. User stories • Sprint backlog • Daily stand-up • Sprint burn down • Other ideas

  28. Other ideas? Your opinion matters • 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. US-25504 Document viewer 2 story points Q.C. Passed 25504 U.A.T. Passed 25504

  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 • …

  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”

More Related