AgileBill Krebs. Agile3d Academy. Enterprise Open Distributed. Agile Quality. Years 30 Books 240. Certs 8. Badges 6. O, Rq, Pm, Qa, Ns, Agile 01

Transcription

1 Agile3d Academy AgileBill Krebs Agile Quality Enterprise Open Distributed Years 30 Books 240 Certs 8 Badges 6 O, Rq, Pm, Qa, Ns, Agile 01

2 Agile Testing: A Practical Guide for Testers and Agile Teams By Lisa Crispin and Janet Gregory (c) 2011 Agile Diimensions LLC CC BY SA

3 Color coded roles BA, Test, Dev, PM

4 Product Backlog A Two Week Sprint In Release Stretch Every day: Standup at task board Pair, unit test, refactor, review Test, integrate, build, test Process Retro Later Releases Sprint Backlog m t w t f M T W T F Product Demo Time

5 Ron Jefferies 3 C s A User Story Building Block Card As an online shopper, I can ship to a friend Conversation Talk with Bob, my stakeholder Confirmation Test: No more, No Less: [x] Can retrieve friend s address [ ] Can specify ship date and carrier [ ] Can track order

6 BDD Triggers Given When Then And

7 Example BDD Acceptance Test BDD. Noun. Behavioural Driven Development Given the user has no existing account When they request to create a new account, Then they are presented with a screen to enter a valid user name and valid password per rules as defined on our team wiki And the information is saved upon submitting. 7

8 From by Elisabeth Hendrickson

9 CI QA From by Elisabeth Hendrickson

10 From by Elisabeth Hendrickson

11 The 5 minute cycle IndustrialLogic.com

12 Acceptance Test

13 Fixtures Column Action Row Calculate Set

14 A Sprint Calendar Mon T W T Fri Plan Do Do Do Do Do Do Do Do Demo Retro

15 Do Daily Meet Dev CI-Build [ Pair, UT, Refactor ] Test ( Refine )

16 Extreme Quality Traditional Extreme Code Inspections Pair Programming Unit Test Automated Unit Test (Test Driven Development?) Daily Builds Continuous Integration

17 Pairing Two people, one computer. Switch Save ½ the bugs for +15% labor Best benefits are intangible

18 Microsoft Research Pair Programming What s in it for me Andrew Begel, Nachiappan Nagappan, Microsoft Research Pair programming is a practice in which two programmers work collaboratively at one computer on the same design, algorithm, or code. Prior research on pair programming has primarily focused on its evaluation in academic settings. There has been limited evidence on the use, problems and benefits, partner selection, and the general perceptions towards pair programming in industrial settings. In this paper we report on a longitudinal evaluation of pair programming at Microsoft Corporation. We find from the results of a survey sent to a randomly selected 10% of engineers at Microsoft that 22% pair program or have pair programmed in the past. Using qualitative analysis, we performed a large-scale card sort to group the various benefits and problems of pair programming. The biggest perceived benefits of pair programming were the introduction of fewer bugs, spreading code understanding, and producing overall higher quality code. The top problems were cost-efficiency, (work time) scheduling problems, and personality conflicts. Most engineers preferred a partner who had complementary skills to their own, who was flexible and had good communication skills.

19 Top 10 Benefits (%) 66 Fewer Bugs 42 Spreads Code Understanding 48 Higher Quality Code 42 Can Learn from Partner 30 Better Design 22 Constant Code Reviews 22 Two Heads are Better than One 17 Creativity and Brainstorming 14 Better Testing and Debugging 13 Improved Morale

20 Formal Inspection Different styles Save ½ the bugs for +15% labor Does it fit in a 3 day story?

21 Cost of change Place these: Pairing Unit Test Build QA bug Inspection Customer bug $$ Series 1 a b c d e f g h i j Time -> (c) 2011 Agile Diimensions LLC CC BY SA

22 Patterns

23

24 Refactor these Smells I Group Smells Duplication Names Alternative classes, Duplicated code Inconsistent, Type embedded, uncommunicative Code issues Complicated boolean expression, Long method, long param list, magic number, null check, simulated inheritance Class Complexity Too many instance variables, methods, or lines Dead code, speculative generality See Refactoring Workbook, by William Wake

25 Refactor these Smells II Group Smells Data Inheritance Data class, data clump, primitive obsession, temporary field Inappropriate intimacy (subclass from), Lazy class, Refused Bequest Responsibility Feature envy, inappropriate Intimacy (general), message chain, Accommodating Change Libraries Combinatorial explosion, divergent change, parallel inheritance hierarchies, shotgun surgery Incomplete library See Refactoring Workbook, by William Wake

26 Q A

27 Agile Testing Quadrants (Brian Marick)

28 Agile Testing Quadrants

29 Agile Testing Quadrants

30 Agile Testing Quadrants

31 Agile Testing Quadrants (Brian Marick)

32 Agile Testing Pyramid (Mike Cohn)

33 To Automate or not? Usability tests? Manual exploratory testing? Customer testing? Prototype code?

34 Engineer test code for the long term Design Patterns Inspect or Pair Readable code Refactor Object Orient reuse Design testability into your system

35 Test Data Should we mock out database calls? Should we we use real customer data?

36 BA Assemble this puzzle QA Dev Show the Tester Cust TDD Create a Story Refactor Customer Test Automate Write acceptance test Exploratory Test

37 Acceptance Test BDD Style BDD Behavioural Driven Development Given the user has no existing account When she requests to create a new account, Then she is presented with a screen to enter a valid user name and valid password (rules defined on wiki) And the information is saved upon submitting. 37

38 Continuous Integration (CI)

39 Examples of Automation Tools API Test Tools Fit, FitNesse, Cucumber, Robot Framework, Concordion, JBehave, Jubala, GUI Dancer GUI Test Tools Selenium, Watir, Canoo WebTest, Twist, rspec Unit Test Tools junit, nunit, WatiN (UI), WatiJ, White Web Services CrossCheck, SoapUI, Ruby test::unit Misc. Dbfit 41

40 Read more via Janet Gregory co-author of Agile Testing softwareqatest.com opensourcetesting.org testingfaqs.org (c) 2011 Agile Diimensions LLC 42 CC BY SA

41 Standup 9 None "ABCs" weekly Stand Up Finish in under 15 minuites "ABC's" are common Task Board 1 None Have Organized Remote Limit WIP Burndown 9 None Have Update In 1 Sigma Decide Code Review 9 None Some Common Efficient Styles Dev Unit Test 3 None Do Auto In Build Tandem Automated QA Test 8 None Have Use Sufficient Measure Coverage QA 8 None Chunks TETO (Test Eary, Test Often) Exploratory "ility" testing Build 1 None Automation "Daily" Auto Tests On demand & Visible Done Done Done 7 None Defined 50% met 80% met 95% met (c) 2011 Agile Diimensions LLC CC BY SA

42 Quality Advocate Does Development Inspect or Pair? TDD or Automated Unit Test? Automate Acceptance Tests? (FIT) Use Continuous Integration?