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 turn 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 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. In some of my articles I write more about test design. You can find them on LogiGear’s Hans Buwalda profile page.
He is a pioneer of the keyword approach for software testing organizations, and he assists clients in strategic implementation of the Action Based Testing™ method throughout their testing organizations. Hans is also the original architect of LogiGear’s TestArchitect™, the modular keyword-driven toolset for software test design, automation and management. Hans is an internationally recognized expert on test automation, test development and testing technology management. He is coauthor of Integrated Test Design and Automation (Addison Wesley, 2001), and speaks frequently at international testing conferences.
Good Article.
Hello, I am aware this is perhaps somewhat strange to hear, but this post inspires me to get through the day, when my coworkers are complaining to me left right and centre! A bunch of my buddies told me about it but I didn’t find it for quite a while, so a couple days back you can imagine how pleased I was to finally stumble upon it! Myself, I don’t do much blogging due to time constraints but I do love to look at other people’s work. I just wanted to comment to show my admiration for your blog and I also wanted to let you know that many authors don’t get any credit for their work, credit that is, in my opinion well deserved. Given the topic you may not believe it and maybe even doubt that any sane person could like it so much, but I honestly wish for you to carry on with this. It’s number 1!