1. Testing under the Agile Method CSCI 521 Software Project Management based on the book Testing Extreme Programming by Lisa Crispin and Tip House

2. Agile Principles Communication ◦ Onsite Customer ◦ Pair Programming Courage ◦ Collective Code Ownership Simplicity ◦ Refactoring Feedback ◦ Small and Frequent Releases ◦ Testing  Every piece of code in the repository also has unit tests.  Programmers write unit test before the code.  Acceptance Tests validate functionality described in User Stories. Review

3. Ideal Agile Process 1. customer writes stories 2. Acceptance Tests created for each story 3. team creates effort estimates of stories to build Release Plan 4. 1 st iteration of the Release Plan is divided into Sprints 5. code and unit tests created at same time Actually, all this happens and once and the user stories are constantly changing. Review

4. User Stories A user story is a description consisting of one or more sentences in the everyday or business language that captures what a user does or needs to do as part of his or her job function. User stories are used with agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. It captures the "who", "what" and "why" of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for business users or customers as a primary way to influence the functionality of the system being developed. User stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.), [ [ https://en.wikipedia.org/wiki/User_story Review

5. Why Agile Testing is Better With traditional methods, Tests are based on the System Requirements Spec, but requirements change and the SRS is not kept up to date ◦ Agile builds test and code at same time Gaps development between customer expectations expressed in original SRS and the final product. ◦ Agile requires frequent releases to the customer

6. A Tester's Role in Agile Some versions of Agile have only "coders" and "customers", no "testers". A "tester" is coder with a focus on producing tests instead of code. Testers understand coding and quality assurance. While coders assume it will work, testers assume it will have problems. Testers take the view of the customer/user.

7. Tester Job Duties Help clarify stories. Help negotiate quality with the customer. Work with customer to write effective Acceptance Tests, including quality. o functions, load, performance, security, installation, etc. Help with estimates during planning. Help team automate testing. Report test results. Help programmers design testable code. Help insure speed does not impede quality. page 32

8. Activity Identify as many questionable or incorrect assumptions as you can in the following statement: Testers run tests, and running test requires that the code be written, and no code is available until the end of the first iteration. Therefore, the earliest the tester is needed is the end of iteration 1. They do other things too. There should be code available on day one of coding. User Stories also need "testing". page 251

9. Rules for Testing All tests (unit tests and acceptance tests) are automated. No integration of new or refactored code is complete until 100% of unit tests pass. No integration is complete until 100% of previously passed acceptance tests pass. ◦ I.e, no going backward in functionality. page 120

10. Rules for Testing Manual Testing:NO! Chapter 19

11. Quality Kent Beck: "There is a strange relationship between internal and external quality. External quality is quality as measured by the customer. Internal quality is quality as measured by the programmers." "If you deliberately downgrade quality, your team might go faster at first, but soon the demoralization of producing crap will overwhelm any gains you temporarily made from not testing, or not reviewing, or not sticking to standards."

12. Quality External Quality examples: o Whenever the user makes a mistake, a user-friendly error screen appears. o It's impossible to crash the server via the user interface. o The system can handle 100 concurrent logins o The system will stay up 99.995% of the time. Internal Quality examples: o 85% of unit level defects are found by the automated unit tests. o 80% of estimates are within 20% of actual. o 90% of the stories for an iteration are completed, on average. o 100% of projects deliver a product to the customer. page 96

13. Metrics Despite Agile's goal of being lightweight, metrics are necessary for feedback (communication). A "tracker" is needed. ◦ Should not be the "tester". ◦ Either the project leader or a senior developer. Essential Metrics: ◦ iteration velocity, start and end dates ◦ story estimates v. actual ◦ task descriptions, status, estimates, actual ◦ notes from daily scrums page 219

14. Metrics continued Keep all these automated metrics in a very visible place so the team sees them every day:  NCSS - Non-Commenting Source Statements  Cyclomatic Complexity  Counts of packages, classes, functions, …  Status of acceptance tests  Number of unit tests written today o percentage of unit tests passed is expected to be 100%

15. Activity You are building a web site for a rural telephone co-op. Story: Create a screen that will allow the user to search on the Web for businesses by category of business and location. As the Tester, identify missing assumptions.  What is the expected load?  What load is needed to make this profitable?  Can we reuse this code to search for persons?  Search by just category, or also search by business name?  What if that category does not exist?  What fields should be on the screen?  What do the search results look like? Chapter 8

16. Activity For each of these questions, indicate whether it is more widening or narrowing. Does the user need to log in to use the system? When a user clicks the link, should the documentation display in the current browser tab or a new tab? How many search terms should the user be able to enter on this page? Would a user ever have to change any of this information? What's the maximum length for the customer name? widening narrowing