Woohoo! My favourite topic. I'll see if I can condense 15 years into a single post. Paolo, you may have to translate this into UML.
You're both right. And on the first steps of a fairly long journey. So let's make a couple of truism statements.
1) A use case is a model of an outcome of an interaction between a system user and the system. The outcome can be achieved or not acheived.
So, we have some scenarios, basic, alt and etc that describe for a particular set of conditions, whether the specified outcome will or will not be achieved. In sophisticated models, the designer can even specify what should happen if the outcome is and is not achieved.
2) From the testing pov, we are interested in the scenarios of each use case. Because that lets us classify our outcomes as "wins" or "losses". This is important because all wins must win and all losses must lose. If not then the system does not operate as expected/desired.
3) Stakeholders cannot understand 2), [size=9](which has made me fairly comfortably well off and generally despised by a small group of designers and developers BTW)[/size] but they do more or less understand a well presented use case.
Proposal: A test case is a model of system usage by one or more actors with a specified set of conditions.
It is convenient, for the purpose of reporting to stakeholders as to whether a specific release of the system is of sufficient quality to warrant implementation, to talk about whether a given set of use cases, targeted for that release, do or do not provide outcomes aligned with the agreed scenarios. Further, it is important to re-assure the stakeholders that existing user facility will not be degraded by the implementation.
So, for a given release of the system, we want to establish a set of test cases whose results, taken as a whole can be communicated to the stakeholders in a manner that lets them make an educated guess as to whether it will be beneficial, within the scope and mandate of the project (expressed or unexpressed), to allow the release to be implemented.
At this point I'm going to raise that most dreaded of all use cases, "Log In". It has an outcome that I will specify as, "The user, attempting to access the system at that node, is granted a set of privileges within the system according to their registered profile for a certain time period given that they are known to the system, have presented valid credentials and are not currently accessing the system from the same or any other node currently accessing the system." I realize that this is probably the best description of said supposed use case that you have seen
but it's for illustrative purposes.
There are but two scenarios (so far), a) the user is granted said privileges and b) the user is denied said privileges. Now lets add a couple of commonly seen system functionalities i) you only get three tries and if you fail then 30000V is delivered through the keyboard, ii) you are informed that the system has never heard of you, but because you look like a nice guy then we'll let you register as a new user, and c) you are told that you are obviously a moron but if you calm down and count to 10 slowly, we'll send you an email with your password (but only if you know your mother's milkman's next door neighbour's dog's collar colour). Hee hee hee, so now we have use cases with extensions based on a negative outcome.
So where do test cases fit in to all this? Well, they're obviously not use case instances and given my last bit of ratbaggery, they are not scenarios either. Further, they are not a single classifier as they have temporal features i.e. a result per release (In fact they can have a result per test cycle, but I've only got 1200 characters left, so I'm going for some brevity here).
In fact, I reckon that use cases are from earth, EA is from the moon, UML is from Mars and users are from a small planet near Betelgeuse (and Dog knows where the heck stakeholders are from). Test cases apparently have to tie these all together.
But after all, they are just a model.
A model expressing how an (giggle) impartial observer might view the system in (giggle) question.
(Not giggling now). Neither UML nor EA has an adequate way of expressing this model (in my experience). The best you can achieve, within these two constraints is to get the use case/scenario model right. Then and only then have you basis for creating a related test model.
I have spent over ten years doing this, exactly. When I first met Paolo, I was still trying to merge testing into EA models. Since then I have developed a system that utilizes use cases and scenarios from an EA model as the basis for a test model. They do not belong in the same model, I think.
I've only got a few chars left in this post so, just let me know whether you want to hear more or not. Because I have sure got a lot more to say on this matter (as well as others in case you're not worried yet)
br
bruce
