Agile Testing

591 views
522 views

Published on

- Understand the principles behind the agile approach to software development
- Differentiate between the testing role in agile projects compared with the role of testers in non-agile projects
- Positively contribute as an agile team member focused on testing
- Appreciate the challenges and difficulties associated with the non-testing activities performed in an agile team
- Demonstrate a range of soft skills required by agile team members

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
591
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Failure to meet the purpose / solve the problem it was designed for - DSDM allows for user testing all through the development process, thus allowing developers to get prompt feedback on the usability and suitability of the product.
    Cost outweighs benefits, or cost is too high altogether - In DSDM, a Business Study is done at the beginning of the project, greatly decreasing the likelihood of late surprises in the financial realm.
    Poor communication between involved parties - DSDM stresses communication and collaboration between all interested parties - developers, users, etc.
    The users finds the program either too hard to use that it does not work as expected - DSDM allows for user testing all through the development process, thus allowing developers to get prompt feedback on the usability and suitability of the product.
    Hidden flaws surface in the system due to poor design or implementation - In DSDM, prototyping helps to ensure that the system is designed correctly and that everyone knows how it will work. Unit testing helps to uncover hidden bugs, and incremental development allows for user testing all through the development process.
    Users resist the instantiation of the system, either for political reasons, or a lack of commitment to it - In DSDM, since the users are actively involved in the development of the system, they are more likely to embrace it and take it on.
    The system is in-flexible and/or un-maintainable, and unable to adapt to change - Since DSDM emphasizes flexibility in design, this is not likely to happen with DSDM.
  • Scrum, occurs in small pieces, with each piece building upon previously created pieces. Scrum emphasizes empirical feedback, team self management, and striving to build properly tested product increments within short iterations.
    Unlike XP, Scrum methodology includes both managerial and development processes.
    this emphasis on an ongoing assessment of completed work is largely responsible for its popularity with managers and developers alike. But what allows the Scrum methodology to really work is a set of roles, responsibilities, and meetings that never change. If Scrum’s capacity for adaption and flexibility makes it an appealing option, the stability of its practices give teams something to lean on when development gets chaotic.
  • Team sprint focus is to get a failing customer to pass.
    Team daily focus is to get failing developer tests to pass and then refactor.
  • Q1: Test Driven Development
    Measure “internal quality” of system
    Small unit tests drive design of small part of code.
    Larger integration tests drive system design
    Automated, in same language, done by programmers
    Run often and at every checkin

    Q2: Story Driven Development
    Measure “external quality” of system
    Story tests drive higher level system design
    Tests are more functional; more examples & combinations
    Tests boundary conditions, error handling, presentation

    Q3:
    Some tests in Q2 may be incorrect or incomplete
    Team may misunderstand, agile customer may omit or forget something
    Emulate how a real user would use the system
    Manual testing – requires a human
    Exploratory/session based testing

    Q4:
    Performance, robustness, security etc.
    Sometimes not given enough focus on agile teams
    Often requires specialized tools & expertise
    * Tests on right hand side feed into stories/tasks for left hand side




  • Q1: Test Driven Development
    Measure “internal quality” of system
    Small unit tests drive design of small part of code.
    Larger integration tests drive system design
    Automated, in same language, done by programmers
    Run often and at every checkin

    Q2: Story Driven Development
    Measure “external quality” of system
    Story tests drive higher level system design
    Tests are more functional; more examples & combinations
    Tests boundary conditions, error handling, presentation

    Q3:
    Some tests in Q2 may be incorrect or incomplete
    Team may misunderstand, agile customer may omit or forget something
    Emulate how a real user would use the system
    Manual testing – requires a human
    Exploratory/session based testing

    Q4:
    Performance, robustness, security etc.
    Sometimes not given enough focus on agile teams
    Often requires specialized tools & expertise
    * Tests on right hand side feed into stories/tasks for left hand side




  • pair testers with developers for:
    exploratory testing
    testing bug fixes
    recreating newly found bugs
    automating tests
    fixing and testing "trivial" bugs as they are found - bugs that will only get fixed in geological timeframes
    have testers report on overall product quality (I was recently introduced to "Low Tech Testing Dashboards" by Paul Carvalho that is perfect for this)
    use testers as "consultants" and treat them as experts
    shift testers to a lead role directing whole team testing close to release
    use cards to drive exploratory test sessions
    consider bringing in "outside" testers for fresh perspectives
    voids the waste of tracking
  • Agile Testing

    1. 1. Agile Testing D A Y 1 – A G I L E P R O C E S S E S S H U C H I S I N G L A , P M I - A C P , I T I L ( F ) A N D I S E B 1
    2. 2. Agenda - Day 1 Introduction to Agile Test Approach – Agile Way Roles in Agile Exercise 2
    3. 3. Waterfall’s Demise 3 Problem Serialized Process Planning far in advance Lack of visibility Project Timeline Static Requirements Consequences Strict sequential chain of the project phases. Previous phase has to be completed before starting the next phase. Products no longer match reality by the time they are released Teams don’t realize they are behind schedule until end Working model can only be seen at end Timeline is planned at the start. If one phase is delayed all other phases are also delayed. Requirements cannot be changed or modified in middle. In larger and complex projects about 60% of the initial requirements are changed throughout the project
    4. 4. Agile’s Rise 4 Problem Serialized Process Planning far in advance Lack of visibility Project Timeline Static Requirements Agile’s Solution Iterative approach with tasks broken into small increments Plan for what we know, and we have left sufficient allowance in our plans for what we don’t know. Allows customer feedback throughout the process. Expectations of the customer are reset at the beginning of each new iteration based on the previous iteration. Delivers working software frequently, from couple of weeks to months; with preference for shorter time scale Scope is never closed; Continual reassessment of requirement priorities by the business
    5. 5. Agile an Introduction 5
    6. 6. Agile - Introduction 6 Agile is an alternative to traditional waterfall, It helps teams respond to unpredictability through incremental, iterative work cadences, known as sprints.
    7. 7. 12 Principles.. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7
    8. 8. 12 Principles.. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity — the art of maximizing the amount of work not done — is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 8
    9. 9. Agile Manifesto 9
    10. 10. Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 10
    11. 11. Individuals and interactions over processes and tools Focus on empowered, self-managing teams Autonomous teams do not need the day-to-day intervention of management Management protects team from outside interference Agile teams are amalgamation of varied professional skills Agile team members are able to step in for each other as necessary 11
    12. 12. Working software over comprehensive documentation Traditionally we measure progress by the percent complete of the functional milestones Agile teams provide actual working product as a status report, “product review” Design changes as the system is built, results in outdated documentation Agile teams prefer face-to-face communication over documentation which is simpler, faster, and more reliable 12
    13. 13. Customer collaboration over contract negotiation Contract negotiation, Identify and define everything and spells out the payment and date specifications Customers become a part of the development process Writing specs down and throwing them over the fence is simply not effective 13
    14. 14. Responding to change over following a plan It’s much easier to respond to change when the organization and the customer share a clear understanding of the project’s status In plan-driven environments, all requirements are specified up front, broken down to the task level and estimated Agile plans follow more of a rolling wave approach using top-down planning 14
    15. 15. Agile Methodology 15
    16. 16. Introduction to Agile Methodology Agile methodologies embrace iterations Small teams work together with stakeholders to describe requirements for the iteration, develops the code, and defines and runs integrated test scripts, and the users verify the results It promotes adaptive planning, evolutionary development & delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change 16
    17. 17. DSDM 17 Dynamic Systems Development Method focuses on: Delivery of the business solution, rather than just team activity. Ensure the feasibility of a project before it is created. It stresses cooperation and collaboration between all interested parties. Makes heavy use of prototyping to make sure interested parties have a clear picture of all aspects of the system.
    18. 18. DSDM 18
    19. 19. Scrum 19
    20. 20. Test Approach – Agile Way 20
    21. 21. Test Approach – Agile Way 21
    22. 22. Session Based Testing A method specifically designed to make exploratory testing auditable and measurable on a wider scale.
    23. 23. Session Based Structure Charter Session ReportDebrief Parsing Results
    24. 24. Agile Quality – A Team Deliverable Agile Practice Benefits Whole Team • Quality is not just a tester responsibility • Quality is more than just testing • Testing role shifts to quality infusion throughout project life cycle Continuous Integration • Developers cannot check in code with failing tests Continuous Testing • Avoids long delays with “big-bang” testing after the “final build” • Bugs found closer to when they are introduced making them easier to fix
    25. 25. Agile Testing Challenges Team may not value testers Testers may not value team Unclear role of testers on team Testing is often squeezed as deadlines approach Developers and testers are often in different operational silos Team may not have the skills or domain expertise to develop/test effectively
    26. 26. Agile Testing Approach Testers are first class citizens on agile teams and part of the “whole team” supporting customers, business stakeholders, developers and other team members Testers support quality infusion through entire team and product cycle Test tasks and stories are planned and executed like development tasks and stories Automate where possible and use session-based testing for exploratory testing Communicate through information radiators
    27. 27. CritiquesProduct SupportsDevelopment Brian Marick’s Agile Testing Matrix Functional Tests Customer Tests Story Tests/Examples User Acceptance Tests Exploratory Tests Usability Tests Unit Tests Integration Tests Performance Tests Load Tests Customer Facing Technology Facing Automate Tools Manual Q1 Q2 Q3 Q4 Automate
    28. 28. CritiquesProduct SupportsDevelopment Tester Activities Product Specifications Test Ideas Testing UAT Design Exploratory Testing Usability Testing Test Ideas Test Development Testing Test Scripts Testing Test Analysis Customer Facing Technology Facing Product Owner Collaboration IT Collaboration Customer Collaboration Developer Collaboration Q1 Q2 Q3 Q4
    29. 29. Agile Testing Iterations Previous Iteration Stories Working Product Q3, Q4: Product Testing Current Iteration Stories Working Product Q1: Testing & Collaboration Next Iteration Stories Working Product Q2: Planning & Test Ideas
    30. 30. Roles in Agile 30
    31. 31. Agile Team 31
    32. 32. Product Owner Single person responsible for maximizing the return on investment (ROI) of the development effort Responsible for product vision Constantly re-prioritizes the Product Backlog Final arbiter of requirements questions Accepts or rejects each product increment Decides whether to ship Decides whether to continue development Considers stakeholder interests
    33. 33. Scrum Development Team Cross-functional (e.g., includes members with testing skills, and often others not traditionally called developers: business analysts, domain experts, etc.) Self-organizing / self-managing, without externally assigned roles Negotiates commitments with the Product Owner, one Sprint at a time Intensely collaborative Most successful when located in one team room, particularly for the first few Sprints 7 ± 2 members Has a leadership role
    34. 34. Scrum Master Facilitates the Scrum process Helps resolve impediments Creates an environment conducive to team self-organization Captures empirical data to adjust forecasts Shields the team from external interference and distractions to keep it in group flow (a.k.a. the zone) Enforces timeboxes Keeps Scrum artifacts visible Has no management authority over the team Has a leadership role

    ×