Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Make It Break

Luke Hefson
January 23, 2013

Make It Break

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

Luke Hefson

January 23, 2013
Tweet

More Decks by Luke Hefson

Other Decks in Technology

Transcript

  1. Why oh why? • Support loads are lessened • Product

    quality is improved • Product reputation is improved • A more holistic view of all products
  2. 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…
  3. Test Manifests A list of test cases that can be

    worked through methodically to catch issues.
  4. 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
  5. 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
  6. 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
  7. File it right! # Steps to reproduce # Expected results

    # Actual results # Additional Notes (Try to include)
  8. 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.
  9. Use your current knowledge of what you’re looking at to

    mitigate risk and optimize your testing time.
  10. Use your current knowledge of what you’re looking at to

    mitigate risk and optimise your testing time. And at the same time…
  11. 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.
  12. Tenacious Don’t let a bug go. If you see it

    – report it. …or at least make a quick note
  13. 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.
  14. Sensitive Empathy towards users at all time. Empathy for the

    people who built what you’re testing. Be honest… but be cool.
  15. 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.
  16. • 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