O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

The Tester Role & Scrum

Carregando em…3

Confira estes a seguir

1 de 21 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (20)


Semelhante a The Tester Role & Scrum (20)

Mais de Johan Hoberg (20)


Mais recentes (20)

The Tester Role & Scrum

  1. 1. THE TESTER ROLE & SCRUM How do Testers fit into the Scrum Framework?
  2. 2. Introduction – This presentation • This presentation outlines my views on a tester’s place in the Scrum Framework • This is based on my experiences in my context, and may or may not be applicable to you
  3. 3. Scrum Framework [1]
  4. 4. The Tester Role How do we define the Tester role? Do we need to define the Tester role? Competence, not role, is the key in this discussion
  5. 5. Generalizing Specialists (or Specializing Generalists) [2]
  6. 6. KEY MESSAGE #1 Competence defines what you do – not role
  7. 7. How to use Test Competence? • If you have competence within test, what can you use that competence for? • Testing? Obviously. • Something else?
  8. 8. Agile Test Quadrants [3]
  9. 9. Code & Architecture Design • By supporting developers and software architects, someone with test competence can help create better designed software • Acceptance Criteria • Testability • Test Automation
  10. 10. Acceptance Criteria Given / When / Then Writing good Acceptance Criteria requires a testing skillset
  11. 11. Testability [5] The practical testability of a product is how easy it is to test* by a particular tester and test process, in a given con- text†. Practical testability is a function of five other  “testabilities:”  project-related testability, value-related testability, subjective testability, intrinsic testability, and epistemic testability  (also  known  as  the  “risk  gap”). Just as in the case for quality in general, testability is a plastic and multi-dimensional concept that cannot be usefully expressed in any single metric. But we can identify testability problems and heuristics for improving testability in general. Interesting Testability Dynamics
  12. 12. Test Automation With competence both in test and in automation a person can add value through test automation
  13. 13. Coaching & Retrospectives • Someone with test competence should also coach the other members of the Scrum Team to improve their competence in this area • During the Sprint Retrospectives someone with test competence could also provide a different perspective on what went well and what needs to be improved for future sprints
  14. 14. KEY MESSAGE #2 Testing is infused into everything & test competence can be valuable in many activities
  15. 15. Who tests what? (Simplification) Anyone Someone with System Competence Someone with Test Competence Someone with Test Competence
  16. 16. KEY MESSAGE #3 Handling complexity is key component in test competence
  17. 17. Competence not Role • Everyone is a tester, but not everyone has the competence to handle those complex testing problems • Focus on your competence and continuously develop it – don’t put any value in what your role is called
  18. 18. Test Competence in a Scrum Team • The Development Team is responsible for testing • Each developer is responsible for testing whatever he/she develops • But sometime they may need some help • If the team dumps all their testing on you, the team is not working properly and this should be brought to the Scrum Master’s attention • But with Test Competence you are in a unique situation to help other members of the team to investigate complexity • Help the team with complex test problems • Allow and support the team to handle simple and complicated test problems themselves
  19. 19. KEY MESSAGE #4 As someone with test competence you are an important part of the Scrum Team, that can support the team in unique ways
  20. 20. Conclusion • Competence defines what you do – not role • Testing is infused into everything & test competence can be valuable in many activities • Handling complexity is key component in test competence • As someone with test competence you are an important part of the Scrum Team, that can support the team in unique ways
  21. 21. References [1] The Scrum Guide http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf [2]To combine … or not http://angryweasel.com/blog/to-combine-or-not/ [3] Agile Testing Quadrants http://www.developsense.com/presentations/2014-06-Dublin-RSTAgileTesting.pdf [4] Acceptance Criteria http://www.leadingagile.com/2014/09/acceptance-criteria/ [5] Heuristics of SoftwareTestability http://www.satisfice.com/tools/testable.pdf [6]Cynefin http://en.wikipedia.org/wiki/Cynefin

Notas do Editor

  • There are meetings and artifacts described in the Scrum Framework
    These are not the end goal – these are a way to reach the goal
    Which is self organizing teams
    Once a team is self organizing, they themselves can choose how they want to work
  • “A lot of people seem to think that discipline-free software teams, everyone can do everything – which is, of course, flat out wrong. Instead, it’s critical that a good software team has (generalizing) specialists who can look critically at quality areas that span the product.”

    “There also will/must be folks who live entirely in the outer ring, and there will be people like me who typically live in the outer ring, but dive into product code as needed to address code problems or feature gaps related to the activities in the outer loop. Leaders need to support (and encourage – and celebrate) this behavior…but with this much interaction between the outer loop of testing and investigation, and the inner loop of creating quality features, it’s more efficient to have everyone on one team.”

  • James Bach

    Build something
    As we do so we – build cleanly and simply
    So that we can – build something with change in mind
    As we do so we – foster testability
    So that we can – study what we have built
    As we do so we – experiment imaginatively and suspiciously
    So that we can – discover something worth building
    As we do so we – develop the design
    So that we can – build some of it
  • “Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.” [4]
    “Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. Acceptance criteria constitute our “Definition of Done”, and by done I mean well done.” [4]
    The Given/When/Then format is helpful way to specify acceptance criteria:
    Given some precondition When I do some action Then I expect some result
  • James Bach

    Working to improve testability is also a key part of a testers job
    Make sure the right skills and tools are available
    Highlight the need of designing a product that is testable
    Make sure the right communication channels are in place
    Make sure test oracles are in place
    And so on …
  • Test automation is very difficult to get right.

    You need the right tools, the right strategy, and the right competence.

    You need to start with realistic expectations, and know that it is a long term investment.

    Make it work for one test case first, and then expand. Don’t try to do everything at once.
  • Scrum is founded on Empirical Process Control [3]
    Empiricism asserts that knowledge comes from experience and making decisions based on what is known [3]
    Testing is not something you just do at the end of a sprint – it is infused into basically every activity
  • Using the Cynefin (Kih-neh-vihn) framework [6]
    Simple tests can be done by anyone (unless you want to automate it, in which case you need to know how to do that obviously)
    Sense – Categorize – Respond
    Simple = easily knowable.
    Complicated tests are well suited for someone with a good understanding of the system
    Sense – Analyze – Respond
    Complicated = not simple, but still knowable.
    Complex tests are well suited for someone with a good testing skillset and a good understanding of the system
    Probe – Sense – Respond
    Complex = not fully knowable, but reasonably predictable.
    Chaotic tests are … difficult?
    Act – Sense – Respond
    Chaotic = neither knowable nor predictable.
  • There is a place for someone with a strong testing skillset both in the Scrum Team, and outside of the Scrum Team
  • There is a place for someone with a strong testing skillset both in the Scrum Team, and outside of the Scrum Team