How To Break Things Really Good #heweb11

View Presentation Description and Presenter’s Bio.

John Boyd from North Park University (@octothorp) started with a bang, or blow, by encourging us to “tap into your inner vandal”. Breaking things when you test is good (yes, GOOD!). This session was packed with helpful tips. Personally, it brought about many “doh! why didn’t I do this?!” moments.

Assumptions John made:
– you launch elements outside your site’s usual functionality. (Not just editing content.)
– you are responsible for overall quality somehow. or you care. (We do care, John.)
– you don’t like things to suck. (Surprisingly, no one walked out here. )

He’s assuming problems about the site.

The point is you want to solve problems before the users do. This doesn’t just happen in IT.  Any of us, marketing/communications, admissions, can solve problems about the site. However, for this presentation, John focuses on web applications.

It’s even important with multi-channels communications. Examples of those: URL on a printed place, social media driving traffic to the site, and stand alone mobile aps.

Jon encourages sharing of stories of things we should have tested. Some common issues are processes, technical, CSS, etc.

4 principles and 7 techniques, which totals to 11 for MMP11.
(and it’s 11-11-11 in 17 days. Coincidence, I think not?)

4 PRINCIPLES

1. Don’t assume it works.
   This is the number 1 things a tester could keep in mind. This common mantra in our world is always the one thing people forget. Actually submit the forms, because it could be a flat .jpg and not an actual form (a hysterical april fools joke, anyone?).Copy has typos. Impossible for it not.  (One to remind the marketers.)How to keep yourself motivated? Listen to Bob Dylan’s “Everything is Broken” – the anthem for quality testers – while testing. “Broken lines, broken strings.” Was Bob Dylan somehow also an early developer?
2. Remember the Humans.
   Technology is personal, human, emotional. You should be not only friendly but friends w/ the developers.John recommends:
   – meeting face to face,
   – talking about things you love about the testing or project
   – admit your own ignorance at what they are good at and ask them to bring you up to speed on how to understand,
   – pay homage to their SKILZ.If all else fails, bring them food. Don’t be afraid. If you do all these things, good developers will appreciate that you’re doing the above and helping them find bugs. 
3. It’s not paranoia if they really are trying to hack you.
   It’s inevitable that someone could be probing your site, or social sites. Marketing/communications people shouldn’t assume all is happy and things will go well.A little paranoia goes a long way.
4. Let things break well.
   When something breaks well “it doesn’t explode”. When things break badly, you have a much larger problem on your hand. Bad breaks cascade into nightmares.
   Example: O rings in boaster rockets in the ’80s.
   Another example of a bad break: not including validation errors or required fields on crital fields in forms, like not required a zip code for the “mail me a catalog” form.Remember to be happy with a little less than perfection. You eventually have to settle and publish the darn thing.

7 TECHNIQUES to keep in mind while testing. (Or disciplines for those of us who need to improve.)

1. Take the time to test.
   Easy advice to give, hard advice to take.  Consider testing like copy editing, or design reviews.
   Copy editor are trained to put a dot above every single word. They are actually trained to slow down.For quality assurance testing, it’s your JOB TO SLOW DOWN. No points for finishing first. (iinsert “doh!” moment here.) Because you will find problems! You will need time to get things fixed.  How much time? judgement decision.Test parts early if you can. This could save time. However, you still need to test the entire piece at the end.Force yourself to look everywhere look at browser titles. Don’t just scan the page like a user. (here’s another “doh!”)Must discipline yourself to slow down.
2. Take great notes and write great bug reports.
   This ties in with remembering the humans. How frustrating is it to hear, “a page doesn’t work” instead of a descriptive explanation of what happened and where?Bug noting resources:
   – from Joel Spolsky’s blog post: http://8to.me/bug-reports
   1. ID steps to reproduce. What page were you on? Critical to be able to fix.
   2. What you expected to see?
   3. What you saw instead?
   (I’m serious considering leaving these three questions as my voicemail message.)- Acrobat Professional for annoted PDFs.- Notable. Found at notableapp.com. Very cool. Able to markup things as you see it in the browser, or the code, you can circle and add comments, your colleagues can see and share.- Bug herd. Found at bugheard.com. Cooler one. Charging now. Offers a plugin for browser.- Fogbugz. Found at http://www.fogcreek.com/fogbugz. More traditional menu tracking.
3. Pay attention to instructions – then violate them.
   You ought to ignore instructions. Why? Because users don’t read instructions.
   Example: “enter the phone number with hyphens.” When testing don’t type in hyphens. See what happens.Validation is a classic thing to test. Does it erase all your other form fields when you get a validation error? When forms are left blank, are you still able to follow up?If anything that needs a manual, it need to be redone.
4. Don’t try it only once. Variations are revealing.
   Example: leave 1 digit off of a credit card number on your giving form. Try all variations and mutations. This is the basic principles of genetics!
5. Watch the other end of the pipe.
   If you tested front end, you need to look in the back end. Check out database. What is the result of your users actions? Remember to read and test confirmation pages and emails that go to the users, or the data emails sent to administrators.
6. Listen to that nagging little voice. Because no, it won’t be OK.
   Even if it’s the fourth round of testing, still listen to that voice.
7. Watch for value in what you’re doing. (I appreciate John ending with a good warm fuzzy.)
   Partly to keep your spirits up. Finding problems can be a downer, but finding problems is creating value for you and your users.Example: inquiry for for prospective students. The email didn’t get to admissions. This is a silent fail. When John turned it back on, 40 came in in just a few weeks!Watch for it because you are not testing to achieve perfection for perfections sake. The point is not to be perfect, the point is to find value for your user and institution.

To sum it up, “Whatever you do, make it fail. make it fail before your users do. it’s your job. so break it really good!?”

John Boyd, North Park University
@octothorp #heweb11 #mmp11
slides and resources: http://8to.me/mmp11