The Tester Role & Scrum

Editor's Notes

1. 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
2. “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.”
3. 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
4. “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
5. 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 …
6. 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.
7. 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
8. 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.
9. There is a place for someone with a strong testing skillset both in the Scrum Team, and outside of the Scrum Team
10. There is a place for someone with a strong testing skillset both in the Scrum Team, and outside of the Scrum Team