Integrate Agile Testing into the Process CS 577b Software Engineering II -- Introduction 13 June 2018 Integrate Agile Testing into the Process CS 577b Software Engineering II Supannika Koolmanojwong © 2002-6 USC Center for Software Engineering

Outline How to integrate agile concept in testing Definition of Done Acceptance Criteria HW 1

Agile Testing Practices TDD Pair Programming Refactoring Continuous integration

Why testing at the end does not work ? It is hard to improve the quality of an existing product Think about legacy system or existing system Mistakes continue unnoticed Finding a needle in haystack The state of the project is difficult to gauge Difficult to estimate test & fix activities of the developed product Feedback opportunities are lost Testing is more likely to be cut Ref: Mike Cohn – Succeeding with Agile (2010)

But !! “it will take too much time to test continuously. We need to be realistic and acknowledge that it’s better to test every fifth or sixth sprint.” When you test less often, it takes longer. Usually these are the cases of manual testing. Then, you should start introducing automated testing. Ref: Mike Cohn – Succeeding with Agile (2010)

But !! “it’s more efficient to have testers working one sprint behind the programmers.” If you test one sprint behind, who will you go when you have questions. Efficient for programmer or the team? Ref: Mike Cohn – Succeeding with Agile (2010)

What building in quality looks like? The use of good engineering practices Small hand-offs between programmers and testers Programmer and tester talk about which capability will be added to the product next Tester creates automated tests, programmers code Once both are done, integrate Much test activity on the first day of a sprint Ref: Mike Cohn – Succeeding with Agile (2010)

Nine principles Speed requires discipline Bad shortcuts  short term speed Agile does not need Quality Police, but the ones who know acceptance criteria and risks Lisa Hendrickson: ttp://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf

Lisa Hendrickson: ttp://testobsessed Lisa Hendrickson: ttp://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf

Lisa Hendrickson: ttp://testobsessed Lisa Hendrickson: ttp://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf

Lisa Hendrickson: ttp://testobsessed Lisa Hendrickson: ttp://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf

Lisa Hendrickson: ttp://testobsessed Lisa Hendrickson: ttp://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf

Lisa Hendrickson: ttp://testobsessed Lisa Hendrickson: ttp://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf

Lisa Hendrickson: ttp://testobsessed Lisa Hendrickson: ttp://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf

Lisa Hendrickson: ttp://testobsessed Lisa Hendrickson: ttp://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf

Lisa Hendrickson: ttp://testobsessed Lisa Hendrickson: ttp://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf

Lisa Hendrickson: ttp://testobsessed Lisa Hendrickson: ttp://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf

Definition of Done Checklist of conditions that must be true Must be ready before a backlog is pulled into a sprint during sprint planning

Sample of DoD Upgrade verified while keeping all user data intact. Potentially releasable build available for download  Summary of changes updated to include newly implemented features Inactive/unimplemented features hidden or greyed out (not executable) Unit tests written and green Source code committed on server Jenkins built version and all tests green Code review completed (or pair-programmed) How to Demo verified before presentation to Product Owner Ok from Product Owner http://www.scrum-breakfast.com/2012/11/sample-definition-of-done.html

Sample of DoD Code produced (all ‘to do’ items in code completed) Code commented, checked in and run against current version in source control Peer reviewed (or produced with pair programming) and meeting development standards Builds without errors Unit tests written and passing Deployed to system test environment and passed system tests Passed UAT (User Acceptance Testing) and signed off as meeting requirements Any build/deployment/configuration changes implemented/documented/communicated Relevant documentation/diagrams produced and/or updated Remaining hours for task set to zero and task closed http://www.allaboutagile.com/definition-of-done-10-point-checklist/

How to build a definition of done ? Brainstorm What are essential ? Identify non-iteration/sprint artifacts Which one can not be done every iteration? Capture impediments Identify obstacles why a particular artifact will not be available at the end of the iteration Commitment Get a consensus http://www.gettingagile.com/2007/10/05/building-a-definition-of-done/

Things to look at Installation build Pass all automated tests in staging environment Sign Off Pass Audit Installation Documentation Accepted by Operations Release Notes Updated Training Manuals Updated http://www.gettingagile.com/2007/10/05/building-a-definition-of-done/

http://www. scrumalliance http://www.scrumalliance.org/articles/106-definition-of-done-a-reference

Acceptance Criteria http://nomad8.com/acceptance_criteria/

Acceptance Criteria http://nomad8.com/acceptance_criteria/

HW 1 Based on your project artifacts, distribute user stories among your team members Pick three different user stories to write acceptance criteria Pick one test case to write test procedure No two team members will have the same user stories or test case.

Example of a Test Case

Example of test procedure