Hi
A use case is simply a description of some external behaviour. In that sense
it is just some operation that queries or transforms the business objects of
the system (which is why you need to model enough of the business objects in
order to write an effective use case).
Like all behaviours, a use case has pre and post-conditions that define the
semantics (meaning) of that behaviour. For example, to withdraw cash from an
ATM you might have a use case that could be summed up by:
System::withdrawCash(accountid : String, amount : float)
pre:
amount > 0 and amount <= Account.allInstances->select(id =
accountid).availableFunds
post:
Account.allInstances->select(id = accountid).getBalance =
Account.allInstances->select(id = accountid).getBalance@pre - amount
You can logically derive all the secenarios from these pre and
post-conditions by building a response matrix (a kind of decision table)
which maps input scenarios to outcomes by looking at all the possible
combinations of input logic (and discrete object states, if there are more
than one). For example, scenario one might be:
amount > 0 and amount <= Account.allInstances->select(id =
accountid).availableFunds
Scenario two might be:
amount > 0 and not amount <= Account.allInstances->select(id =
accountid).availableFunds
Scenario three would be:
(not amount > 0) and amount <= Account.allInstances->select(id =
accountid).availableFunds
And scenario four would be:
(not amount > 0) and (not amount <= Account.allInstances->select(id =
accountid).availableFunds)
When you build the software you must consider all the possible scenarios,
and not be selective ("Oh, let's just look at a couple of scenarios")
because if you don't then your use case specification is incomplete. The
worst possible crime is to say "Oh, we can do the other scenarios in the
next iteration"!!! If there are too many scenarios then your behaviour is
too complex and you need to simplify it. Your scenarios must match exactly
what the system testers are expecting, so you do not wait for them to do the
analysis - do it yourself and compare it with what the system testers have
come up with. The TEST is the use case specification (and not the word
document...)
Also, try to avoid scenarios like:
1. The cash is withdrawn
2. Validation fails
This is not helpful.
Regards
Jason Gorman
http://www.xml-objects.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Angay, Huseyin
(Huseyin)** CTR **
Sent: 15 February 2001 12:05
To: '[EMAIL PROTECTED]'
Subject: RE: (ROSE) Test scenarios
You'd rarely ever write the scenarios themselves. (The only time I find
these useful is when going through complicated scenarios with users. Even
then, the scenarios are thrown away once the use case is written.) The use
case text should be able to cover all the scenarios in a general form. The
analyst job is to simplify and generalise scenarios to the point that you
can work out the different scenarios from as little text as possible.
Testers should be given enough training to be able to read the use case text
and write or generate the code for test scenarios from those.
Regards,
Huseyin Angay
Karabash Ltd.
www.karabash.co.uk
> ----------
> From: Antonio Jean Claude[SMTP:[EMAIL PROTECTED]]
> Reply To: Antonio Jean Claude
> Sent: 15 February 2001 9:25
> To: 'Kopetzky, Volker'; [EMAIL PROTECTED]
> Subject: RE: (ROSE) Test scenarios
>
>
> Thanks for your answer,
>
> This was very helpful.
> Tell me if I am wrong: a UC scenario is a instance of a UC. UC scenarios
> should cover all main and alternative flows and their variations. These
> artifacts are created by the analysts.
>
> How detailed should these UC scenarios be?
> Should they be as detailed as :
> SCENARIO 1:
> Message 1
> Attrubute 1 = A1
> Attrubute 2 = A2
> Expected results:
> Object1 created with AttributeA = A1
> Object2 created with AttributeB = A2
> Link created between Object1 and Object2
> Message 2
> ....
>
> plus a written description of the UC scenarios.
>
> In which case, for one use case the analysts can end up with an incredible
> amount of UC scenarios.
>
>
> Or should they only focus on the written description of the UC scenarios
> and
> leave the testers to draw the actual messages?
>
>
> Cheers,
>
> Jean-Claude
>
>
> -----Original Message-----
> From: Kopetzky, Volker [mailto:[EMAIL PROTECTED]]
> Sent: 14 February, 2001 9:06 PM
> To: Antonio Jean Claude;
> "'=SMTP:[EMAIL PROTECTED]'"@ns2.cargolux.com
> Subject: AW: (ROSE) Test scenarios
>
>
> Jean Claude,
>
> well, everyone should provide input for the testers!
>
> It's more the thinking about who owns the requirements that are to be
> tested.
> Every role in your team provides/influences requirements:
> - analysts (e.g. business rules, 'boundary' requirements, ..)
> - designers (e.g. RDBMS mechanisms, Messaging requirements, ..)
> - developers (e.g. coding conventions, implementation requirements, ..)
>
> My suggestion would be that every role provides specific requirements.
> Every (testable) requirement type has an attribute 'Test: yes/no'.
>
> The testers then can filter the requirements and implement the 'requested'
> tests. With some integration, empty test scenarios can be 'precreated',
> and
> the tester also has access to further needed documentation (e.g. a
> UC-scenario
> can be used to navigate to the use case document).
>
> With best regards,
> Volker
> TIPS & TRICKS:
> Try 'Help:Extended Help' in any Rational Tool
> ********************************************************************
> Volker Kopetzky
> Senior Systems Engineer/Expert Phone: +49 / 89 - 62838 - 293
> Rational Software eFax: +49 / 89 - 62838 - 593
> Keltenring 15 Fax: +49 / 89 - 62838 - 269
> D-82041 Oberhaching MailTo:[EMAIL PROTECTED]
> Germany URL: http://www.rational-software.de/exp/vzk
> ********************************************************************
> Rational...
> -> Suite:
> http://www.rational.com/products/rs/index.jtmpl
> -> Requisite Pro:
> http://www.rational.com/products/reqpro/index.jtmpl
> -> Unified Process:
> http://www.rational.com/products/rup/index.jtmpl
> -> Rose - unoffical website:
> http://www.rationalrose.com
> -> Upgrades:
> http://www.rational.com/sitewide/support/upgrades/
>
>
> -----Ursprüngliche Nachricht-----
> Von: Antonio Jean Claude [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 14. Februar 2001 11:11
> An: [EMAIL PROTECTED]
> Betreff: (ROSE) Test scenarios
>
>
>
> Hi all,
>
> This is more a question of organisation than a Rose question.
> Our project is divided into 4 groups:
> - analysts
> - designers
> - developpers
> - testers
>
> The analysts are working on Use Case description and Conceptual Diagrams
> (Class diagram representing Domain concepts). They describe use cases with
> a
> flow or events.
>
> Should they take care of the creation of the Test scenarios?
> If not, who are the best candidates to create them?
>
> Thanks,
>
> Jean-Claude
> ************************************************************************
> * Rose Forum is a public venue for ideas and discussions.
> * For technical support, visit http://www.rational.com/support
> *
> * Admin.Subscription Requests: [EMAIL PROTECTED]
> * Archive of messages:
> http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> * Other Requests: [EMAIL PROTECTED]
> *
> * To unsubscribe from the list, please send email
> *
> * To: [EMAIL PROTECTED]
> * Subject:<BLANK>
> * Body: unsubscribe rose_forum
> *
> *************************************************************************
> ************************************************************************
> * Rose Forum is a public venue for ideas and discussions.
> * For technical support, visit http://www.rational.com/support
> *
> * Admin.Subscription Requests: [EMAIL PROTECTED]
> * Archive of messages:
> http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> * Other Requests: [EMAIL PROTECTED]
> *
> * To unsubscribe from the list, please send email
> *
> * To: [EMAIL PROTECTED]
> * Subject:<BLANK>
> * Body: unsubscribe rose_forum
> *
> *************************************************************************
>
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
