Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Training - Agile Testing

683 views

Published on

This is a training that I conducted on Agile Testing. There is a lot of confusion around how Testing Professionals are impacted when they move from Traditional development models to Agile development models. This training attempted to clear some of the confusion around that.

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

Training - Agile Testing

  1. 1. 1 AGILE TESTING 12/10/2013 Sudipta Lahiri
  2. 2. Agile Testing 2   Agile testing is a software testing practice that follows the principles of agile software development (wikipedia) Involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace 12/10/2013
  3. 3. The role of Agile Testing 3  Agile teams do need testers  People with strong testing skills  They might need QA in a different form/shape!  Your function is to support the business by helping them understand the business and acceptance criteria  Understand risks! 12/10/2013
  4. 4. 4 The 9 principles... 12/10/2013
  5. 5. 5 Testing moves the project forward... 12/10/2013
  6. 6. Testing is not a phase 6 12/10/2013
  7. 7. Everybody tests! 7  Everyone Tests    On traditional projects, independent testers are responsible for all test activities. In Agile, getting the testing done is the responsibility of the whole team. Yes, testers execute tests. Developers do too. The need to get all testing done in an iteration may mean that the team simply cannot do as much in each sprint as they originally thought.    If yes, then Agile has made visible the impedance mismatch between test and dev that already existed. The team was not going as fast as they thought. They appeared to be going quickly because the developers were going fast. But if the testing isn't done, then the features aren't done, and the team just does not have the velocity they think. Goldratt's TOC says that the whole team can only go as fast as the slowest part. 12/10/2013  To go faster, the team has to widen the throughput of the
  8. 8. Reduce feedback latency 8 12/10/2013
  9. 9. 9 Case Study: Test Planning for one release – in 2011 IR Activities Pre Release Defect Validation - Merges ~ all 6.2 HF1 -6.2HF6 = 150 defects Planned Planned Dev Build Start End Team 17-01-11 08-02-11 QA -Aryaans Test Case Development CHR CFT IR1 Cal Total Reso Days PDs urces Rate 3 16-02-11 4 15/day/person 10 2 QA QA ,QA Aryaans 12 60 8 6 4 items ~1000 TCs 17-02-11 01-03-11 Regression Testing ~Tier3 (1000 testcases)-need to skip incase of bandwidth issue Test Case Development 6.3 CHR Testing [Estimated Cases ~ 1000] Merge Defect Validation all 6.2 HF1 -6.2HF5 defects QA -Aryaans QA QA QA 3 10.5 3.5 100 tc/day/person 5 2 25 6 5 65 1 4 4 15/day/person QA Aryaans QA Aryaans 0.5 1.5 0.5 1.75 3 3.5 50/day/person QA Aryaans 1.5 4.5 3 Only rejected defects and automation run critical fixes QA Aryaans 1 1 1 Acceptance Scenario and Unautomated sanity Testing Release Packaging QA Aryaans QA 1 2 TOTAL IR2 01-03-11 Regression Testing ~6000 testcases (Tier1,Tier2 and Tier3 ;these are non automated cases of the modules related to the defects tagged for 6.3 on dhruva) 02-03-11 08-03-11 - 5 cal days -(2000 testcases) 4 QA Aryaans 10 Resources - 80 tc/day/person to fill in the bandwidth for execution of 4000 testcases for 5 cal days Defect Validation - Defect Validation - QA Initiator Closure ~ 50 + - CHR Defects ~100 IR3 QA - Aryaans + 1 QA 10-03-11 18-03-11 13 11-03-11 16-03-11 Defect Validation - Merges ~75 Regression Testing(Unexecuted) ~ 100 testcases Initiator Closure Defect Validation (CHR + Regression ) ~75 IR4 5 100TC/day/person 1000 3 15 defects /day /person 21-03-11 23-03-11 7000 200 We still had regression leaks! 2 2 2 1 203 pds So, 60mm of DCUT needed 20-25mm (10mm for testing + 10 developers for supporting all defects from testing) over a period of 6-8 weeks to make a 12/10/2013 release!
  10. 10. Execution Today 10 Team is delivering continuously... Changes to scope can be taken anytime and delivered in 3-4 weeks Testing is part of the Development process Everyone tests! Development automates UTC; Testing automates ST 12/10/2013
  11. 11. Tests Represent Expectations 11 12/10/2013
  12. 12. Fix bugs asap... keep the code clean 12 12/10/2013
  13. 13. Reduce test documentation overhead 13  Lightweight Documentation: Instead of writing verbose, comprehensive test documentation, Agile testers:       Use reusable checklists to suggest tests Focus on the essence of the test rather than the incidental details Use lightweight documentation styles/tools Capturing test ideas in charters for Exploratory Testing Leverage documents for multiple purpose Leverage One Test Artifact for Manual and Automated Tests   Today, we invest in extensive, heavyweight step-bystep manual test scripts in Word or a test management tool Instead, capture expectations in a format supported by automated test frameworks like FIT/Fitnesse.   The test could be executed manually 12/10/2013 More importantly that same test artifact becomes an
  14. 14. Tested is part of “DONE” 14 12/10/2013
  15. 15. Test Driven (not Testing Last) 15 12/10/2013
  16. 16. 16 4 key practices 12/10/2013
  17. 17. 17 Automated Unit/Integration tests 12/10/2013
  18. 18. Test Driven Development 18 12/10/2013
  19. 19. Automated System-Level Regression Tests 19 12/10/2013
  20. 20. Acceptance Test Driven Development 20 12/10/2013
  21. 21. In summary... 21 12/10/2013
  22. 22. The testing pyramid... 22 Ideal State In most environments Manu al C O S T R O I UI (5%) Services (15%) Unit Tests (80%) UI Services Unit Tests 12/10/2013
  23. 23. But let us understand this in more detail 23 12/10/2013
  24. 24. Impact of Agile Requirements 24  Agile testing must be iterative Agile testers cannot rely on having complete specifications Agile testers must be flexible  The techniques exist to make this possible...   12/10/2013
  25. 25. Testing in the Agile world... 25 12/10/2013
  26. 26. 26 Let us discuss these test cycle more...  Development Team Testing:   Testers are embedded in the development team, working side by side to build the system  Focus of their testing efforts are often on confirmatory testing   Agile teams will take a whole team approach Developer regression testing or better Test-Driven Development (TDD). Parallel independent testing.  Continuous independent testing parallel to construction iterations throughout the lifecycle.  Goal: find defects that got past the development team  Perform higher forms of testing such as system integration testing, security testing, usability testing  Need significant testing skills, complex tools, and often complex pre-production testing environments    10-15:1 ratio between people on the 2 teams In larger organizations, one team can support several development teams Release Testing 12/10/2013
  27. 27. Test Automation 27 12/10/2013
  28. 28. 28 Where can you apply automation? 12/10/2013
  29. 29. TDD 29   Test-FirstDevelopment Developer TDD  Technical doc - JIT  Seen more with pair programming  “Test Immediately” after approach  What happens when we extend this to the next level... 12/10/2013
  30. 30. ATDD 30  TDD at the requirement level      Acceptance TC is a expectation of the customer Write a single acceptance test; make code changes to pass it Requirement spec (JIT) If you do ATDD, you don’t need to TDD necessarily Also, called BDD or user-story driven development 12/10/2013
  31. 31. Some industry trends... 31 12/10/2013
  32. 32. Some industry trends... 32 12/10/2013
  33. 33. Implications for Test Practioners 33       Become generalizing specialists Be flexible. Be prepared to work closely with developers. Once again, be flexible. Focus on value-added activities and again... Be flexible 12/10/2013
  34. 34. 34 Finally... Why Agile Testing works? 12/10/2013
  35. 35. References 35   http://www.ambysoft.com/essays/agileTesting. html http://testobsessed.com/wpcontent/uploads/2011/04/AgileTestingOverview .pdf 12/10/2013

×