My aim here is to tell you that I learned to work with Agility rather than work with the Agile Rituals and Definitions. And I learned to trust that working with Agility trumps Rituals and Definitions the hard way. Because sticking to rituals and definitions led to rigidity, rather than agility. And then "What does testing look like when you adopt that mindset?" In this presentation you will short cut your learning on the topic of Agility, so you understand "What does testing look like when you adopt an Agility mindset?". Applying this mind set naturally leads to incorporating exploratory testing, technical testing, automated execution, end to end testing and risk. Adopting this mindset allows you to fit into any Agile Software Development project and create a customized testing approach that works. Keynote at the internal Rabobank Testing Conference on Feb 15th 2018 in Utrecht. https://www.compendiumdev.co.uk/page/rabobank201802

1. HOW TO TEST WITH AGILITY
ALAN RICHARDSON
> www.eviltester.com/agile
> www.compendiumdev.co.uk
> @eviltester
1 — @EvilTester

2. CONFIDENCE
DO YOU KNOW HOW TO
'AGILE'?
2 — @EvilTester

3. CONFIDENCE COMES WITH EXPERIENCE
> Do you know how to work with 'Agility'?
> Do you know multiple ways to perform a task?
> Can you make decisions?
> Can you take responsibility for those decisions?
3 — @EvilTester

4. RELENTLESS
Relentless - The Japanese way of Marketing by Johny K.
Johansson and Ikujiro Nonaka, 1996
4 — @EvilTester

5. RELENTLESS
"MARKETING BY THE JAPANESE, ... , IS
FUNDAMENTALLY AN APPLICATION OF COMMON
SENSE. ...THEY PREFER
> synthesizing over analyzing,
> common words over professional jargon,
> and simplicity over sophistication."
5 — @EvilTester

6. AGILITY
TRUMPS AGILE
COMPLIANCE6 — @EvilTester

7. "...MARKETING IS TOO IMPORTANT TO LEAVE
TO THE PROFESSIONALS. CUSTOMERS WILL
FALL THROUGH THE CRACKS BETWEEN
SPECIALIZATIONS."
Relentless - The Japanese way of Marketing by Johny K.
Johansson and Ikujiro Nonaka, 1996, pg 7
7 — @EvilTester

8. TO UNDERSTAND HOW TO
"TEST" WITH AGILITY
WE FIRST NEED TO
UNDERSTAND "TESTING"
8 — @EvilTester

9. WHAT DO WE
GET FROM
"TESTING"
NOT "WHY DO WE TEST?"9 — @EvilTester

10. WHAT DO WE GET FROM "TESTING"
> What do we achieve by testing?
> What do we gain from the process of testing?
> What happens if we do not test?
> etc.
WHAT ARE THE OUTCOMES OF HAVING TESTED.
10 — @EvilTester

11. Q: WHAT DO WE GET FROM "TESTING"
A: VARIES DEPENDING ON WHO YOU ASK
| - Confidence | - Bugs |
| - Knowledge | - Assurance |
| - Data | - Information |
| - Automation | - Compliance |
| - Risk Identification | - Risk Mitigation |
| - Change Impact Assessment | - SLA checking |
| - etc. | |11 — @EvilTester

12. IF TESTING WAS QUESTIONING
> How do we know?
> What evidence do we have?
> What if?
> What else?
> etc.
12 — @EvilTester

13. TO ANSWER THOSE QUESTIONS
> We Model Systems
> Identify and explore risk
> Use appropriate communication
> Compare Models to Systems via experimentation and
exploration
... a basic test approach
13 — @EvilTester

14. TEST AGILITY
> Contextual
> Flexibility of approach
> Responsiveness
> Add value & avoiding waste
> Doing/saying the 'right' thing
> etc.
14 — @EvilTester

15. TESTING WITH AGILITY
DOES NOT REQUIRE AN
AGILE PROJECT
15 — @EvilTester

16. AGILE PROJECTS FORCE SOME AGILITY
> reduced documentation
> smaller timescales
> less up front information
> test and develop in parallel
> co-located
> etc.
16 — @EvilTester

17. AGILE RITUALS AND DEFINITIONS
> 3 Amigos, Standups, Retrospective, Story Points, Stories,
Definition of Done
> "Agile", "Devops", "Automation Pyramid", "ATDD", "BDD", "TDD",
"Continuous Integration", "Continuous Delivery", "SDET"
> etc.
NOT REALLY A LOT ABOUT TESTING IN THERE
17 — @EvilTester

18. SOME SEEM TO BE ABOUT TESTING
BUT THEY ARE NOT REALLY.
| - Definition of Done | - Test Driven Development (TDD) |
| - ATDD | - BDD |
| - SDET | - Continuous Integration |
18 — @EvilTester

19. BUT THEY DO PROVIDE SOME OF THE GAINS
WE ASSOCIATE WITH TESTING.
> e.g. Confidence, Assurance, Bugs, Change Impact
Assessment, SLA checking, Automation
19 — @EvilTester

20. TESTING IS NOT THE ONLY
WAY TO ACHIEVE THOSE
GAINS
20 — @EvilTester

21. SO HOW DOES TESTING
FIT IN TO AGILE?
21 — @EvilTester

22. WORKING ON AGILE PROJECTS IS HARD
WHEN WE TRY TO "BE" AGILE
MAKE IT EASIER BY
> working flexibly
> use commonsense communication
> trust yourself
22 — @EvilTester

23. RIGIDITY EXAMPLES
> Paralysis
> Beginners know the rituals but exhibit no variety
> Follow the rituals and it will all work out
> Wait for the coach
23 — @EvilTester

24. I LEARNED TO WORK WITH
AGILITY RATHER THAN
AGILE RITUALS AND
DEFINITIONS.
24 — @EvilTester

25. STICKING TO RITUALS AND
DEFINITIONS LED TO
RIGIDITY, RATHER THAN
AGILITY.
25 — @EvilTester

26. FOCUS ON
OUTCOMES
RATHER THAN PROCESSES
26 — @EvilTester

27. WHAT IS AGILE SOFTWARE
DEVELOPMENT... REALLY?
27 — @EvilTester

28. REGULARLY RELEASE
SOFTWARE THAT WORKS
AND WHICH ADDS VALUE
WITH EACH RELEASE.
28 — @EvilTester

29. SO HOW DO WE
TEST WITH
AGILITY?29 — @EvilTester

30. HOW DO WE KNOW THAT WE... REGULARLY
RELEASE SOFTWARE THAT WORKS AND
WHICH ADDS VALUE WITH EACH RELEASE
> How do we know it works?
> What does 'works' mean?
> How do we know it does what it should?
> How do we know it doesn't do what it shouldn't?
> How do we know it adds value?
30 — @EvilTester

31. WE CAN TEST, TO FIND
ANSWERS TO THOSE
QUESTIONS.
31 — @EvilTester

32. AUGMENT AGILE
PROCESSES
WITH TESTING32 — @EvilTester

33. WHAT DOES AGILE SOFTWARE
DEVELOPMENT LOOK LIKE?
> Goals - Epics, Release Planning
> Stories
> Acceptance Criteria
> Development
33 — @EvilTester

34. HOW MIGHT TESTING FIT INTO THAT?
Goals: Epics, Release Planning
> Questions, Risks
Stories
> Questions, Risks,
> Notes on how to test
34 — @EvilTester

35. HOW MIGHT TESTING FIT INTO THAT?
Acceptance Criteria
> Questions, Risks,
> Notes on how to test,
> What we will cover,
> What we will not cover
35 — @EvilTester

36. HOW MIGHT TESTING FIT INTO THAT?
Development
> Acceptance Criteria Validation,
> Automate Acceptance Criteria Validation for CI,
> Exploratory Testing (based on risk, questions, what we
learn from Acc Criteria Validation, etc.)
36 — @EvilTester

37. WHO DOES ALL OF THAT TESTING?
Anyone, can...
> Questions, Risks, Notes,
> Acceptance Criteria Validation
PEOPLE WITH TESTING SKILLS WILL DO IT
'DIFFERENTLY'
37 — @EvilTester

38. WHO DOES ALL OF THAT TESTING?
People who can code, can...
> Automate Acceptance Criteria Validation for CI
PEOPLE WITH TESTING SKILLS CAN AUTOMATE TO
SUPPORT 'TESTING' NOT JUST 'VALIDATION'
38 — @EvilTester

39. WHO DOES ALL OF THAT TESTING?
People who can test, can...
> Exploratory Testing
> Technical Acceptance Criteria Validation (performance,
security, accessibility)
39 — @EvilTester

40. AGILITY REQUIRES UTILISING SKILLS.
NOT CONFORMING TO ROLES.
We need people who can Test well.
40 — @EvilTester

41. SOMEONE WHO CAN TEST
WELL, WILL SEE
OPPORTUNITIES TO TEST
THAT OTHER PEOPLE DO
NOT SEE.41 — @EvilTester

42. SOMEONE WHO CAN TEST
WELL, WILL TEST BETTER
THAN OTHER PEOPLE.
42 — @EvilTester

43. GIVE PEOPLE
THE TIME
TO APPLY THEIR SKILLS
43 — @EvilTester

44. LET'S GET HUNG UP ON "AUTOMATED
TESTING"
THESE ARE PROCESS QUESTIONS
> Should we automate?
> How much?
> Where? Api? GUI? - Avoid GUI its flaky!
> When?
44 — @EvilTester

45. OUTCOME QUESTIONS
What questions do we want our "Automated Testing" to
answer?
> Does this software continue to work?
> Does this software continue to meet the agreed
acceptance criteria?
> etc.
45 — @EvilTester

46. IF WE CARE ABOUT THE
ANSWER THEN WE DO
WHAT IT TAKES TO GET
THE ANSWER.
46 — @EvilTester

47. ROBUST AUTOMATED EXECUTION
> Multi-skilled
> Commit
> Re-use the Automated Execution for Exploration as
well as Validation
> Part of your project cost and time
Sometimes it isn't worth the effort.
47 — @EvilTester

48. ACCEPTANCE CRITERIA VALIDATION IS NOT
ENOUGH
> How ambiguous is the Acceptance Criteria?
> Does it cover risk?
> Does it cover impact on previous areas of the system?
> Are the examples 'complete'?
48 — @EvilTester

49. HOW DEEP DO YOU HAVE TO OBSERVE
ACCEPTANCE CRITERIA?
> HTTP Traffic?
> Memory Consumption?
> Processor Speed?
> File usage?
49 — @EvilTester

50. EXPLORATORY AND TECHNICAL TESTING
> What if?
> What else?
USING THE RESULTS OF QUESTIONING AND
OBSERVATION TO IMPROVE OUR MODEL AND EXPAND
OUR SCOPE OF TESTING.
50 — @EvilTester

51. END TO END TESTING
> Do we still need to test end to end when we work with
Agile?
> Unit Testing is Design and Conformance
> Automated Execution of Feature Flows
51 — @EvilTester

52. WE NEED AGILITY
WE CREATE A
CUSTOMISED AND
TAILORED PROCESS FOR
OUR ORGANISATION52 — @EvilTester

53. > We build a System Of Development
> We want the System to work effectively in our
environment
> People are part of that System
> We Automate as part of that System
> We Test as part of that System
53 — @EvilTester

54. AGILITY - LESSONS LEARNED FROM
CYBERNETICS
Cybernetics by Norbert Wiener - 1948 - bit.ly/2BA2JqV
54 — @EvilTester

55. AGILITY - LESSONS LEARNED FROM
CYBERNETICS
> Science of Feedback and Control
> Requisite Variety
> Cybernetics by Norbert Wiener - 1948 - bit.ly/2BA2JqV
> see also Stafford Beer, W. Ross Ashby
55 — @EvilTester

56. AGILITY - LESSONS LEARNED FROM MOSHE
FELDENKRAIS
56 — @EvilTester

57. AGILITY - LESSONS LEARNED FROM MOSHE
FELDENKRAIS
"...LEARNING MEANS HAVING AT LEAST ANOTHER WAY
OF DOING THE SAME THING."
"TRY SOMETHING YOU KNOW AND LEARN TO DO IT
ANOTHER WAY."
Moshe Feldenkrais - The Master Moves, 1984
57 — @EvilTester

58. AGILITY - LESSONS LEARNED FROM MOSHE
FELDENKRAIS
"NOW, TAKE A MINUTE TO TRY FOR YOURSELVES
ANYTHING YOU WANT, TO SEE WHAT YOU COULD
IMPROVE IN YOUR MOVEMENT."
Moshe Feldenkrais - The Master Moves, 1984
58 — @EvilTester

59. INDIVIDUALLY: CAN YOU TRUST YOURSELF?
> Do you understand the technologies being used?
> Do you know how to test?
> Do you know how to test these technologies?
> Will you speak out?
> Will you ask Questions?
59 — @EvilTester

60. DO YOU HAVE THE
NECESSARY SKILLS AND
ATTITUDE?
60 — @EvilTester

61. CULTURALLY: CAN YOU TRUST
YOURSELVES?
Agility requires trust in yourself and your team.
> Are you trustworthy?
> Are you skilled?
> Are you experienced?
> Are you flexible?
61 — @EvilTester

62. WORKING ON AGILE PROJECTS IS HARD
WHEN WE TRY TO "BE" AGILE
MAKE IT EASIER BY
> understanding outcomes
> working flexibly
> use commonsense communication
> trust yourself
62 — @EvilTester

63. WORK WITH
AGILITY
63 — @EvilTester

64. END
Alan Richardson www.compendiumdev.co.uk
> Linkedin - @eviltester
> Twitter - @eviltester
> Instagram - @eviltester
> Facebook - @eviltester
> Youtube - EvilTesterVideos
64 — @EvilTester

65. BIO
Alan is a test consultant who works at a technical
level using techniques from psychotherapy and computer
science. In his spare time Alan is currently programming a
multi-user text adventure game, a Twitter Client and
some buggy JavaScript games in the style of the Cascade
Cassette 50. Alan is the author of the books "Dear Evil
Tester", "Java For Testers" and "Automating and Testing a
REST API". Alan's main website is compendiumdev.co.uk and
65 — @EvilTester