Why oh why?
• Support loads are lessened
• Product quality is improved
• Product reputation is improved
• A more holistic view of all products
Slide 3
Slide 3 text
Also, reporting bugs
before they hit genpop
is fucking SATISFYING.
Slide 4
Slide 4 text
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…
Slide 5
Slide 5 text
QA thangs
Slide 6
Slide 6 text
Test Manifests
Slide 7
Slide 7 text
Test Manifests
A list of test cases that can be worked
through methodically to catch issues.
Slide 8
Slide 8 text
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
Slide 9
Slide 9 text
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
Slide 10
Slide 10 text
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
Slide 11
Slide 11 text
File it right!
# Steps to reproduce
# Expected results
# Actual results
# Additional Notes
(Try to include)
Slide 12
Slide 12 text
# Steps to reproduce
# Expected results
# Actual results
# Additional Notes
Slide 13
Slide 13 text
Push Dogfooding
Slide 14
Slide 14 text
Push Dogfooding
Also…
User Scenarios
Plan tests for new features/updates
Constant Review (designs & existing tests)
Slide 15
Slide 15 text
Riiiight…
Slide 16
Slide 16 text
Exploratory testing
HOLLA!!!
Slide 17
Slide 17 text
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.
Slide 18
Slide 18 text
HACKING = TESTING TO LEARN
Slide 19
Slide 19 text
Choose a GitHub app,
or an area of dot com
and start
exploring
Slide 20
Slide 20 text
Use your current knowledge of
what you’re looking at to mitigate
risk and optimize your testing
time.
Slide 21
Slide 21 text
Use your current knowledge of
what you’re looking at to mitigate
risk and optimise your testing
time.
And at the same time…
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
Method Act
Slide 24
Slide 24 text
Assume different roles while
you are testing.
Slide 25
Slide 25 text
Assume different roles while
you are testing.
THE CONFUSED NOOB
THE O.C.D. DEVELOPER
ie.
or
Slide 26
Slide 26 text
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.
Slide 27
Slide 27 text
Besides being
fucking SCHIZO,
it helps if you
are:
Slide 28
Slide 28 text
Tenacious
Don’t let a bug go.
If you see it – report it.
…or at least make a quick note
Slide 29
Slide 29 text
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.
Slide 30
Slide 30 text
Sensitive
Empathy towards users at all
time.
Empathy for the people who
built what you’re testing. Be
honest… but be cool.
Slide 31
Slide 31 text
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.
Slide 32
Slide 32 text
Be wary of…
Slide 33
Slide 33 text
• 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