People who know me and my work probably know my emphasis on good test design for successful test automation. I have written about this in “Key Success Factors for Keyword Driven Testing“. In the Action Based Testing (ABT) method that I have pioneered over the years it is an essential element for success. However, agreeing with me in workshops and actually applying the principles in projects turns out quite often to be two different things. Apart from my own possible limitations as a teacher, I see at least one more reason: The way the testing is involved in the development projects.
A typical development project will start with a global understanding of what the system needs to do, which is then detailed out further, for example into use cases. These use cases have proven to be helpful in implementation and various testing efforts, but I’m getting more and more the impression that they may also pose a risk for good test design when they are the only source of information for the test team. There are two reasons:
1. They tend to have a high level of detail
2. They usually follow the end-user perspective
Re 1: The level of detail of use cases is primarily aimed at the developers, and the information they need to know. More often than not it is implicitly assumed that this is also a good level for information for testers to develop test cases from (for the sake of simplicity I will not discuss the usefulness of techniques like exploratory testing, I will just assume that test cases are made and their execution is automated).
Re 2: In many tests it matters how a system handles transactions, and provides the correct and complete follow up actions and information. The end-user interacting with the UI is then not always relevant, and I would not like to see it explicitly specified as part of test cases (in ABT the UI specifics would be hidden in the ‘actions’). However, having the UI oriented use cases as the primary source of information makes it hard to focus on the transaction handling and other aspects of the system.
My message would be this: don’t start creating test cases from use cases, or similar developer oriented sources of information, before you have had a chance to create a high level test design, in which you specify which test products you’re going to create and what level of detail they would need to have.
Article by Hans Buwalda, CTO, LogiGear Corporation
