1. The small picture
1.1. exploratory testing
1.1.1. gathering information about the system
1.1.1.1. using emergent insights into the system to build up further testing
1.1.2. exploring flows that encompass different acceptance criteria
1.1.2.1. uncovering new acceptance criteria
1.1.2.2. questioning existing ones
1.1.3. using maps with different flows rather than just one route
1.1.3.1. maps have different roads for getting to a destination
1.1.3.2. using as many observers as possible
1.1.4. using ATs to drive the system to different states
1.1.5. leaving no stone unturned
1.1.5.1. be it migration or scila integration
1.1.6. domain language
1.1.6.1. same for everyone
1.1.6.2. clarifying any inconsistencies
1.1.7. questioning everything
1.1.7.1. validity of the story
1.1.7.2. how is the story going to be useful to the business
1.1.8. finding bugs
1.1.9. tools
1.1.9.1. the DSL
1.1.9.1.1. API clients
1.1.9.1.2. Selenium
1.1.9.2. ATs/ITs
1.1.9.3. MindMup
1.1.9.4. yEd
1.1.9.5. proxies
1.1.9.5.1. burpsuite
1.1.9.5.2. fiddler
1.1.9.6. FIX
1.1.9.6.1. wireshark
1.1.9.6.2. xlFix
1.1.9.6.3. MiniFIX
1.1.9.7. custom
1.1.9.8. REST console
1.2. what else
1.2.1. research
1.2.1.1. mutation testing
1.2.1.2. property based testing
1.2.1.3. exhaustive testing
1.2.1.4. data driven testing
1.2.2. backlog
1.2.2.1. minimise Romero runs
1.2.2.2. change ATs to ITs
1.2.2.3. refactor DSL/ATs/ITs
1.2.2.4. profile ATs for test coverage
1.2.2.5. browser compatibility
1.2.3. test third party products
1.2.3.1. Android app
1.2.3.2. iOS app
1.2.3.3. Salesforce; DataCash; Envoy; Jasper; Scila
1.2.4. weekly retrospectives
1.2.4.1. share knowledge about the stories in the sprint
1.2.4.2. actions on what we can improve
1.2.5. rotate
1.2.5.1. into other teams
1.2.5.2. into production support
1.2.5.3. other roles
1.3. A bit about us
1.3.1. paranoid
1.3.2. pedantic
1.3.3. inventive
1.3.4. curious
1.3.5. we like sharing knowledge
1.3.6. sceptical
1.3.7. always looking for the big picture; trying to see the forest from the trees
1.4. what we're not
1.4.1. random clickers
1.4.2. gateway
1.4.3. quality assurance (QAs)
1.4.4. policing the release
2. To finish - what do testers do?
2.1. Use a number of different approaches, techniques, soft skills, hard skills, knowledge, information, context, experience, investigative curiosity, constant learning and much much more to question. We do this in order to provide information, to help gain more information, to help those who need to make decisions. We use different skills and personality traits at different times to achieve what we need to do.
3. The big picture
3.1. participation in the kick off meetings
3.1.1. they question all they can
3.1.2. they take notes
3.1.3. the more examples they see the more they'll be able to analyse and question
3.2. explore existing functionality
3.2.1. look into how the system works at the moment
3.2.2. what other parts might interact with the new functionality
3.3. model
3.3.1. draw
3.3.2. mind map
3.3.3. how the data flows through the system
3.3.4. user scenarios
3.3.5. brainstorm with other people
3.3.6. what about production data
3.4. review existing acceptance/integration tests
3.5. create acceptance and integration tests
3.5.1. collaborate with ba, dev, business
3.5.2. iterate over ATs
3.5.2.1. requirements change
3.5.2.2. understanding changes
3.5.2.3. refactor
3.6. explore new functionality
3.7. stand-ups
3.7.1. understand what progress is being made with the implementation
3.7.2. communicate progress on
3.7.2.1. exploratory testing
3.7.2.2. acceptance/integration tests
3.7.3. ask for help
3.7.4. make sure everybody is on the same page
3.8. showcases
3.8.1. create simple flows of how it all works
3.8.2. never use stubs
3.8.2.1. all services are deployed
3.8.3. use production data if necessary
3.8.4. follow-up on any questions/issues
3.8.5. try and do them as early as possible