Use Case Testing:
The ISTQB syllabus expects the Software Tester at the Foundation level to understand and explain Use Case testing (K2 level). In contrast, the Software Tester has to apply the knowledge in selecting the test cases for the other Black Box techniques (Equivalence Partitioning, Boundary Value Analysis, Decision Table and State Transition – K3 level).
Use cases came out of the Rational Unified Process (RUP) and represent the software application in terms of Actors and the system. Actors are the different users of the system. Use cases are usually present in the Software Design Document.
Consider an application for providing courses. The application has different actors – Provider, Student etc. Each of these Actors accesses a particular part of the application, different screens etc. In other words, they have a specific work-flow designed for each of them.
The Course Provider would login and query/add/modify/delete course information. And also query/add/modify some of the student details.
The Students on the other hand would only be able to query the course information and add/modify their(individual student) details. And schedule and take exams.
Are these the only two Actors for the application or can there be more? When we start thinking this way, we may be provoked into thinking of users we haven’t yet considered – for example an Admin user.
Use cases describe the “process flows” through a system based on its actual likely use, so the test cases derived from use cases are most useful in uncovering defects in the process flows during real-world use of the system. Use case may have preconditions, which need to be met for a use case to work successfully. And each use case terminates with post-conditions, which are the observable results and final state of the system after the use case has been completed.
From the testing perspective:
- Use cases help us identify test cases that exercise the whole system on a transaction by transaction basis from start to finish.
- Test cases based on use cases are called ‘scenarios’.
- Use cases are particularly useful in exercising business rules or process flows
- Use cases also help uncover integration defects caused by the interaction and interference of different components
- Use cases also help identify gaps in process flows and exercise boundaries.
- Use cases are very useful for designing acceptance tests with customer/user participation.