Advertisement
Check these out next
The Tester Role & Scrum
Oct. 20, 2015•0 likes•17,142 views
26 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Engineering
Technology
My views on a tester's place in the Scrum Framework.
Johan HobergFollow
Associate QA Director @ KingAdvertisement
Advertisement
Advertisement
The Tester Role & Scrum
- THE TESTER ROLE & SCRUM How do Testers fit into the Scrum Framework?
- 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
- Scrum Framework [1]
- 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
- Generalizing Specialists (or Specializing Generalists) [2]
- KEY MESSAGE #1 Competence defines what you do – not role
- How to use Test Competence? • If you have competence within test, what can you use that competence for? • Testing? Obviously. • Something else?
- Agile Test Quadrants [3]
- Code & Architecture Design • By supporting developers and software architects, someone with test competence can help create better designed software • Acceptance Criteria • Testability • Test Automation
- Acceptance Criteria Given / When / Then Writing good Acceptance Criteria requires a testing skillset
- 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
- Test Automation With competence both in test and in automation a person can add value through test automation
- 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
- KEY MESSAGE #2 Testing is infused into everything & test competence can be valuable in many activities
- Who tests what? (Simplification) Anyone Someone with System Competence Someone with Test Competence Someone with Test Competence
- KEY MESSAGE #3 Handling complexity is key component in test competence
- 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
- 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
- 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
- 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
- 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
Editor's Notes
- 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
Advertisement