How To Become a Testing Gladiator ANZTB Melbourne Jules Barnes 27 July 2017

Transcription

1 How To Become a Testing Gladiator ANZTB Melbourne Jules Barnes 27 July 2017

2 The Arena is your IT system The Crowd are your Customers The Game Editor is your Business Your opponent is change The battle is testing

3 4 steps to become a testing gladiator

4 Step 1 Training

5 Your Weapons Gladiators Testing Factors Access Controls Audit Trail Authorization Continuity of Processing Correctness Coupling Ease of Operation Ease of Use Integrity Maintainable Methodology Performance Portable Reliability Service Levels

6 Types of Gladiators Gladiator Types Testing Types Accessibility Testing Automated Testing Compatibility Testing Exploratory Testing Functional Testing Penetration Testing Performance Testing Production Verification Testing Regression Testing Security Testing Static Testing System Integration Testing System Testing Usability Testing User Acceptance Testing

7 You need to continually train and practice your skills

8 Step 2 Customer Know your Audience

9 Why know your Customer?

10 Combining your Testing Skills with an understanding of your customer will always result in better quality

11 Wotif.com Test Team Story (2009) Company was rapidly growing, 100% year on year We were testing from the customers perspective, we just didn t know it! "We find 95 per cent of defects before we go into production," Barnes says.^ Agile development teams, testing was embedded from the start Story acceptance criteria was defined by the Testers & BAs Test cases were automated in continuous integration environments by developers New test environments could be deployed within hours Environments were refreshed regularly from production 48 hour performance stability tests were conducted for all major releases All testing was completed within 1 to 2 weeks of major releases from multiply sprints of work Test team could stop a release if it didn t met testing standards ^

12 Step 3 the Business Talk the language of Technology

13 Your testing is too rigorous, we need to get changes out faster and are willing to accept higher risk of defects going into production

14 Not talking the same language Who here has been in a situation like this?

15 Test Cases Low risk to the Business

16 Test Cases Higher risk to the Business

17 Testing reduces the likelihood of risk

18 Test Cases How much risk is the Business willing to accept?

19 Example Risk A customers ability to find and book a room caused by a new search results interface may result in reduced bookings or reduce NPS. Consequence Catastrophic / Major / Moderate / Minor / Insignificant Likelihood Very Likely / Likely / Possible / Unlikely / Rare What testing would you do to reduce the Likelihood?

20 What did we just do? 1. Identified a risk [Event that has an effect on objectives] may result in [consequence/s] caused by [cause/s] 2. We assessed Consequence based on the may result in statement 3. We agreed on a likelihood based on our understanding 4. We then conducted test design to work out what would be required to reduce the likelihood of that risk from occurring

21 Step 4 Bringing it all together

22 New problem How do we combine our testing skills with our understanding of customer expectations to communicate risk to the business?

23 Low risk to the Business?

24 Higher risk to the Business?

25 Create a Customer Journey Map

26 Map the supporting business processes Map the supporting IT systems

27 Example Use Case Example Risk A customers ability to find and book a room caused by a new search results interface may result in reduced bookings or reduce NPS. The Change a new search results interface The Impact A customers ability to find and book a room The Consequence 1. Reduced bookings 2. Reduce NPS

28 Step 1: Continually Train Step 2: Know your Customers Step 3: Talk the language of the Business Step 4: Bring it all together Repeat 4 steps to become a testing gladiator

29 Call to Action Create a Customer/Business/Technology map

30 Q&A