Jan
31
Requirements-Based Testing
January 31, 2006 |
…is the name of the symposium I’ll be presenting at BAWorld Toronto in May.
Business Analysts are frequently responsible for testing systems as well as for specifying them. If you read most books on testing, you will find a lot of advice written with the assumption that the tester has never been near an end-user of the system. This session will show you how to build requirements documents that you can easily verify later. We will discuss how to build test cases that efficiently cover your requirements to avoid duplicated effort, how to plan tests more efficiently for a system when the testers understand what they need it to do, and identify the key requirements that are most critical to system functionality.
Sounds good, I hope.
What I want to do with this seminar is give people an idea how to build effective test cases. Most testing methodologies suggest that test cases be scripted to the Nth degree–go to this screen, click this, check the wording of the response, etc. That may be the way to go if your testing is being done by people who don’t have any idea of what the application is supposed to do. That’s not the case for most BAs. A BA needs to evaluate whether the system can meet the business need first, and then worry about wording of error messages and the like. The goal of this seminar will be to break down a requirements document into a set of discrete requirements and then identify business cases that test multiple requirements–so that you can assure appropriate breadth of coverage without creating more test cases than necessary.