Mickey Phoenix - started with Selenium and merged with FitNesse. Needed a name Narrative Testing. Problem most people don't think in terms of truth tables (aka FitNesse).Users think in terms of the data presented to them by the program.

Start with the User Stories and ask the user to tell their story in terms of their expectations in . Hierarchical decomposition.

Verify that Empty log entries display properly

Erik Petersen - relates the idea that this can be used as a functional specification written before the UI exists. This requires a scripting based language.

Mickey - wants tool that allows the GUI to displayed as the test is run so that the user can see the story being executed with the GUI being executed at the same time.  Like Karaoke. Variable speed tool would be handy so you speed past the boiler plate.

Mickey - values extensibility of tools - so if tools don't already support say database you can extend it - add a noun to the language.

Mickey - In older projects the cost of maintaining the tests over time came to dominate the effort. Problem lack of modularity, reuse - made changes very difficult

James Lyndsay - pitfalls of discussion - choosing testing architecture up front influences coding choices down the line. Story: Initially wrote one login block, eventually needed different login blocks. Multiple login blocks duplicated code. Some things are tough to parameterize (i.e. Multiple machines, multiple browsers at the same time). Weaknesses in the testing tools i.e. Not supporting login from multiple browsers forced team to choose to throw error and restrict otherwise good design choices.

Mickey - customer's language naturally hints at hierarchy and structure. Must be as aggressive about refactoring test hierarchy as main line code.

Mickey - when you start writing code the user has to trust that the code does what they intend, so bury code down the hierarchy and hide it. Example: complex assertion for one customer about the definition of enabled for  - details hidden in selenium javascript.

Pekka Laukkanen (sp?). Reported on his use of Robot Framework is unifying framework that allows you write in DSL (keywords) - written in a spreadsheet - verb in one column, parameters in others. Robot doesn't have its own testing engine instead it can be mapped to other lower level tools (Selenium, SSH, easy to roll your own library). Value:

Mickey - robot isn't a narrative testing tool: can't see the test execution on the fly i.e. See the story and the app at the same time; can't take a test expand the decomposition lacks an IDE.

Erik - Robot grew out XXX that sat on top of WinRunner and Rational Functional Tester

Mickey - currently very difficult and slow to integrate with CI.

Paul King - Canoo WebTest an extension of ant - calls htmlUnit - can use emulator (rhino browser) or real browser to run tests. Used in conjunction with WebDriver.

Paul King - business natural languages allow customer to be able express their concepts in a language slightly closer to English.

Mickey objects that Customers should be prepared to handle verb noun combinations.

Paul - Keywords vs. DSL's - DSL's may also included programming constructs.

Mickey - narrative testing excludes programming constructs if/then, looping entirely because customers don't speak in those terms: i.e. Little red riding hood ... If meet wolf then...

Mickey - prefers nouns and verbs (or atoms in DSL) vs. keywords.

Mickey - have the conversation with the customer about what an account is - have it once and encode it in the DSL.

Mickey - writing your own DSL tends to pay for itself in reduced test maintenance costs.

James goes to suggest that the tests are often the weakest at the interfaces - i.e. Boundaries between the various bits of software that interact - example Word.

Questions:

Tools that got mentioned

Sites of interest

Narrativetesting.org (in progress)

Opensourcetesting.org