Some thoughts on Use Cases
I was recently questioned about the pre and post conditions of use cases and decided to share a few thoughts here.
A pre-condition of the whole use case is presumed to be true. You do not test the pre-condition inside the use case, nor do you have an exception case for the pre-condition being false.
A post-condition of the whole use case is guaranteed to be true. Inside the use case, you must include statements so that the post-condition is always true no matter what alternative or exception is executed.
You will often find that the post-conditions of one use case are the pre-conditions of another use case, especially when working with lower-level (more detailed) use cases.
When writing pre and post conditions of a use case, think of the use case as a black-box atomic unit with well-defined inputs and outputs. Imagine that you are testing the use case in such a way that you cannot see its internal behavior - all you have access to are the pre and post conditions.
If you insist that you have different pre-conditions and post-conditions for different paths through the use case, then you do not have different paths through one use case. Instead, you have different use cases.
If you look at the use case in a white box manner, you may wish to define internal pre and post conditions of parts of the use case. These would represent internal state changes of the use case.
I see many people handling pre and post conditions of the use case in a very casual manner. I don't have a problem with that as long as it is clear that the writing is intended to be casual rather than rigorously correct.
A rigorous use of pre and post conditions is of great benefit to the testing team. It may be that the testing team will rewrite the pre and post conditions to be technically correct in order to assist in the testing process.
0 Comments:
Post a Comment
<< Home