In the evening there was a non-competitive Testing Exhibition in which a number of the bigger names present gave a 5 minutes talk about how they tested the CAST2007 registration page (which everyone has admitted was a pretty broken page/process). It was lots of distractions not helped by Google’s open bar, but here are the things I thought were interesting.

James Bach

  • Demented Happy Path – Happy Path testing, but with an ‘Oops. Didn’t mean to do that, I should go back and fix it

Rob Sabourin

  • The belief held by the tester of what might be the most valuable type of bug(s) might differ (dramatically) from that the product owner (customer) — test for what the customer really wants you to test for. Of course, they might not actually be able to articulate it to you, but that is the normal requirements problem we’ve been grappling with for 40 years and counting
  • We spiders are a category of user
  • Another mindmap tool, this one is even free. FreeMind
  • Put test ideas on index cards. Have those cards colour coded according to what bucket the apply to in order to give your ‘unstructured’ testing structure
  • For each type of user, think of at least 3 different actions they could do: Good, Bad, Screwed Up
  • Look at each type of user, and what it is that they are supposed to be doing to derive the actual requirments of the system

Lydia Ash

  • Before going too far down a testing road, as the customer “Do you want me to do testing type X?”
  • Look at the cost of a category of bug and give it appropriate weighting. For example, AST pays $10 / month in hosting fees. It does not make sense to look at every type of bug that might make it use more bandwidth (invalid caching headers, site partitioning, etc)

Harry Robinson

  • Weinberg’s Second Law – If Builders Built Buildings The Way Programmers Write Programs, Then The First Woodpecker That Came Along Would Destroy Civilization.
  • Test where the logic is (in this case, all the logic was behind in the backend process)

Danny Faught

  • You always need to do an end-to-end test
  • Call the phone numbers that are on the page. Email the email addresses
  • On toolsmithing
    • Proactively offer to observe the tester and offer suggestions where a tool might augment their testing
    • Offer you service to testers, but don’t force a tool on them if they don’t want / need it
    • Testers should not feel like they cannot use a tool without having their toolsmith approve it