Agile testing
Download as PPTX, PDF1 like40 views
The document introduces agile software testing, highlighting the limitations of the traditional waterfall model and the benefits of agility, such as early feedback and collaboration between teams. It outlines key practices for successful agile testing, including the whole team approach, continuous integration, and exploratory testing. Additionally, it describes the Scrum framework, roles within it, and key scrum events that facilitate effective agile development and testing.
Agile testing
- 1. An Introduction to Agile Software Testing
- 2. Hello! I am Joe Phan I’d like to give you a view about agile testing. You can find me a: ◆ https://www.linkedin.com/in/joe-phan-28b25a120/ ◆ Grenade.Eminem@gmail.com 2
- 3. When do we test? 3
- 4. Waterfall model - SDLC 4
- 5. Traditional Model Limitations ◆ Impossible to anticipate and estimate all tasks early in big projects ◆ Difficult to define requirements precisely without customers getting Hands On feel of product ◆ Changes later in the development cycle could be expensive to handle ◆ Working software delivered only at end of cycle 5
- 6. Waterfall Problems ◆ Late delivery ◆ Over budget ◆ Wrong thing is delivered ◆ Testing “bottleneck” at end ◆ Heavyweight documentation 6
- 8. What is Agility? Values, principles and practices that foster team communication and feedback to regularly deliver customer value through working software. 8
- 9. 9
- 10. Agile Approach Use big image
- 11. Separate Teams Use big image
- 12. How Agile Changes Things ◆ Whole Team Approach ◆ Coding and Testing are One Process ◆ Feedback, collaboration key ◆ TDD/ATDD practices ◆ Test-infected developers 12
- 13. A Team Use big image
- 14. The 7 Success Factors for Agile Testing ◆ Use the whole team approach ◆ Adopt an agile testing mindset ◆ Automate your regression testing ◆ Provide and obtain feedback ◆ Build a foundation of core agile practices ◆ Collaborate with customers ◆ Look at the big picture 14
- 15. Do Your Best Work ◆ Whole Team approach Collaborate with customers, developers ◆ Business examples, turned into tests ◆ Agile Testing Quadrants ◆ Test Automation Pyramid ◆ Exploratory testing 15
- 16. Whole Team Approach ◆ Team commitment to quality ◆ Team responsible for testing ◆ Testers get support, training ◆ Anyone can do any task ◆ Testers transfer testing knowledge ◆ Collaboration 16
- 17. Early and Frequent Feedback ◆ Avoiding requirements misunderstandings ◆ Clarifying customer feature requests ◆ Discovering (via continuous integration), isolating, and resolving quality problems early ◆ Providing information to the Agile team regarding its productivity and ability to deliver ◆ Promoting consistent project momentum 17
- 18. Testing is Not a Phase ◆ Development = testing + coding Write test, write code, test ◆ Unit and Acceptance Test levels ◆ Automated tests Free time for exploratory testing 18
- 21. What is Exploratory Testing? ◆ Exploratory testing is a testing approach where you explore the system and venture into those aspects and functionalities which may or may not directly affect the system’s outputs, in order to find underlying errors. ◆ The purpose of performing exploratory tests is to learn more about the system and its functionality and using your existing knowledge about the system to find errors. 21
- 22. Scrum Process
- 23. Sprints ◆ Scrum projects make progress in a series of “sprints” ◆ Typical duration is 2–4 weeks or a calendar month at most ◆ A constant duration leads to a better rhythm ◆ Product is designed, coded, and tested during the sprint ◆ Product is potentially shippable after every Sprint 23
- 26. Roles ◆ Product Owner • Defines features and release plans • Responsible for development schedule and prioritizing Product Backlog • Accept or reject work results • DARK - Desire, Authority, Responsibility, Knowledge (Business and Technical) ◆ Scrum Master • Coaches the development team and responsible for productivity • Facilitates Scrum ceremonies • Establishes and enforces Scrum rules and responsible for the success of the process • Shields the team from noise and removes obstacles • Enables close cooperation across all roles 26
- 27. Roles ◆ Team • Cross-functional:Programmers, testers, user experience designers, etc. • Responsible for self-organising tasks and committing to work (no one assigns stories or tasks to team members, team must self- organise) • Teams are self-organizing 27
- 29. Sprint planning (4 hours + 4 hours) 29
- 30. Sprint Events ◆ Daily scrum meeting (10-15 mins) • What did you do yesterday? • What will you do today? • What is blocking your work? ◆ Sprint review • Demo of new features to customer/product owner • Team presents work accomplished during the sprint • All major stakeholders participate ◆ Sprint retrospective • Periodic post mortem to review what's working and what's not • Short workshop session for team to review lessons learned and discuss actions for the next Sprint • All major stakeholders participate30
- 32. Product backlog ◆ A list of all desired work on the project ◆ Ideally expressed such that each item has value to the users or customers of the product ◆ Prioritized by the product owner ◆ Reprioritized at the start of each sprint 32
- 33. A sample product backlog 33
- 36. QA Activities in Agile Testing ◆ Provide effort estimates during release and sprint plan ◆ Collaborate with business analysts and developers in defining requirements and designs ◆ Prepare test conditions based on design discussions • Just in time test cases only for current sprint and not entire project ◆ Execute test conditions and report issues • Usually, test driven development ◆ Automate feature specific test cases ◆ Report status, impediments in daily standup meetings ◆ Participate in Sprint review meeting36
- 37. Testing Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc. Checking vs. Testing Checking Checking is confirmative (verification and validation of what we already know). The outcome of a check is simply a pass or fail result; the outcome doesn’t require human interpretation. Hence checking should be the first target for automation. 37
- 38. Checking vs. Testing James Bach points out that checking does require some element of testing; to create a check requires an act of test design, and to act upon the result of a check requires test result interpretation and learning. But its important to distinguish between the two because when people refer to Testing they really mean Checking. 38
- 39. Checking vs. Testing Michael Bolton : “A development strategy that emphasizes checking at the expense of testing is one in which we’ll emphasize confirmation of existing knowledge over discovery of new knowledge. That might be okay. A few checks might constitute sufficient testing for some purpose; no testing and no checking at all might even be sufficient for some purposes. But the more we emphasize checking over testing, and the less testing we do generally, the more we leave ourselves vulnerable to the Black Swan. 39