STAREast 2014: Days 1 & 2

Michael Bolton and James Bach are friends with the same people: Cem Kaner, Doug Hoffman, Paul Holland, and James’s brother Jon. The material in their full-day tutorials at STAREast 2014 covered some of the same material I was exposed to at CAST 2013 and the BBST Foundations course I just finished. Luckily, Michael and James were good enough speakers that the techniques still felt fresh and motivating. I would have tweeted the following if this conference provided WiFi beyond the registration desk.

On prioritizing and finding bugs:

  • Your clients are your boss, the development team and the customer in that order.
  • Usability problems are also testability problems because they allow bugs to hide.
  • Create a test plan before looking at the specification to generate more ideas.
  • Describing your entire test plan allows others to participate in your thinking.
  • The slowest test you can do is the test you don’t need to do.
  • Testers should look for value in the software, not bugs.
  • Memorizing types of heuristics and techniques will help you internalize them.
  • Automated tests are like a check engine light; they only tell you where more investigation is needed.
  • No amount of testing proves that the product always works.

On reporting bugs:

  • Report bugs concisely.
  • Treat boundary requirements as rumors.
  • Separate observation from inference with safety language (i.e. “It appears to be broken” instead of “It’s broken”).
  • Some things are so important or so embedded in the culture (tacit knowledge) that we don’t need to write them down (explicit knowledge).
  • Testers should report bugs and issues. Bugs threaten the value of a product to someone who matters. Issues threaten the value of the testing or business.
  • Testing reports should include the status of the product, how you tested it, and how good that testing was.

Important questions to ask without accusing:

  • Can I ask you lots of questions?
  • Is there any more information?
  • Do you have any particular concerns?
  • Is there a problem here?
  • Can I help you with tasks you don’t like so you have more time to answer my questions?

On the testing profession:

  • Testing is learning about a product through experimentation. And creating the conditions to make that happen. And building credibility with developers.
  • Testing stops when our client has enough information to make a shipping decision.
  • You will never have a complete specification.
  • In Agile, everyone should be willing to help each other answer questions, not abandon their roles or expertise.
  • It is emotionally draining to constantly be fighting with someone who can make your life difficult.
  • Testing is the opposite of Hollywood: The older you are, the better it gets.
  • Testers can’t fear doubt or complexity.
  • A tester’s main job is not to be fooled.
  • Bureaucracy is what people do when everyone has forgotten why they’re doing it.
  • Our job is to tell developers their babies are ugly.
  • Music and testing are a performance. Sheet music : music :: documents : testing.
  • Apple makes you forget its products don’t work. Microsoft keeps reminding you.

*Originally published at [murphyslawtester.wordpress.com](https://murphyslawtester.wordpress.com/2014/05/07/stareast-2014-days-1-2/) on May 7, 2014 and duplicated on [Medium](https://medium.com/@ezagroba/stareast-2014-days-1-2-37db44094016).*