Make It Break

Using exploratory testing as an optimized solution for quality assurance within GitHub.

Transcript

1. Make It Break
2. Why oh why? • Support loads are lessened • Product quality is improved • Product reputation is improved • A more holistic view of all products
3. Also, reporting bugs before they hit genpop is fucking SATISFYING.
4. Quality shouldn't be added later – it's more prevention than detection. The process of testing can find bugs but it can't demonstrate their absence. If you don't find bugs after a good testing, that doesn't mean there is no value to your time! However…
5. QA thangs
6. Test Manifests
7. Test Manifests A list of test cases that can be worked through methodically to catch issues.
8. Test Manifests A list of test cases that can be worked through methodically to catch issues. Focus on: UI interactions, known areas for regression, new features, updated views, early exit code, speed and load-bearing
9. User Feedback We already do this :) 1. Receive a support request about an issue 2. Recreate the issue (& get more info if needed) 3. File it! 4. Thank the user profusely
10. User Feedback We already do this :) 1. Receive a support request about an issue 2. Recreate the issue (& get more info if needed) 3. File it! 4. Thank the user profusely
11. File it right! # Steps to reproduce # Expected results # Actual results # Additional Notes (Try to include)
12. # Steps to reproduce # Expected results # Actual results # Additional Notes
13. Push Dogfooding
14. Push Dogfooding Also… User Scenarios Plan tests for new features/updates Constant Review (designs & existing tests)
15. Riiiight…
16. Exploratory testing HOLLA!!!
17. So, exploratory testing isn’t the same thing as dogfooding. Dogfooding is using your own software day-to-day. Whereas exploratory testing is navigating the software under different thought processes.
18. HACKING = TESTING TO LEARN
19. Choose a GitHub app, or an area of dot com and start exploring
20. Use your current knowledge of what you’re looking at to mitigate risk and optimize your testing time.
21. Use your current knowledge of what you’re looking at to mitigate risk and optimise your testing time. And at the same time…
23. Method Act
24. Assume different roles while you are testing.
25. Assume different roles while you are testing. THE CONFUSED NOOB THE O.C.D. DEVELOPER ie. or
26. Assume different roles while you are testing. THE CONFUSED NOOB THE O.C.D. DEVELOPER (show yourself how to use GitHub) (How do I do this edge-case thing?) ie.
27. Besides being fucking SCHIZO, it helps if you are:
28. Tenacious Don’t let a bug go. If you see it – report it. …or at least make a quick note
29. Honest Don’t be afraid to let someone know about an issue they may have introduced. Or, a feature that doesn’t work as it is intended.
30. Sensitive Empathy towards users at all time. Empathy for the people who built what you’re testing. Be honest… but be cool.
31. Into it If you find an issue, take a moment to savour it. You found this fucker and it’s going to make everyone’s life better because you did.
32. Be wary of…
33. • Operant Conditioning* • Automate whenever possible • Slowing down development Ignoring issues because you are ‘used to them’ Script, or delegate to hubot things that don’t need manual testing GitHub moves unlike any other software company. Optimize QA. *blog.regehr.org/archives/861
34. and don’t forget
35. fucking file it right