Alex Imrie’s talk has the distinction of being the one I took the most notes in. In a nutshell, it was about when and how to handle when things blow up in your scripts. And they will. In her intro she said that she “shouldn’t be here” since she comes from a linguistics background. I would argue that makes her more qualified than most to be there; we need an even more diverse set of backgrounds thinking about stuff in test.

  • We want our automation results to be constant
  • Some definitions
    • An ‘event’ is a deviation from plan
    • An ‘exception’ can be handled in the script
    • An ‘error’ can’t be dealt with in the automation
  • I think I have a problem with the chosen terminology since they already mean one thing in a programming context and now we’re overloading them with something else. The distinction and need for a name though is valuable
  • Events can happen from the development process, the test environment or the test platform. Ideally we want them to be in the platform as that is where the interesting things are from a testing perspective.
  • The big solution to these is really better communication (we knew that) but also one can try to build in some manual tester intelligence
  • React to the real issue, not the inherited problem
  • Use state validation before and after an action — which can clutter the script, but is valuable especially things like Selenium which will happily click on a hidden field.
  • But of course that means state hooks were added for you.
  • If you can’t eliminate dependencies, at least know them
  • Setup and teardown are often the most complex parts of automation
  • ‘Local’ event resolution has the workaround in the test itself
  • ‘Global’ event resolution is more like a high level exception handler that logs a message and then bails out of the script
  • Can your teardown work in both happy and sad test situations?
  • Start with a Global handler and add Local ones as needed
  • Continuous Integration + AUtomated Testing = Merciless Transparency