Hi, Jason.
What you describe works as a rigorous program specification, but I think it
is stretching the spirit of use cases quite a lot.
> ----------
> From: Jason Gorman[SMTP:[EMAIL PROTECTED]]
> Reply To: Jason Gorman
> Sent: 15 February 2001 12:29
> To: Angay, Huseyin (Huseyin)** CTR **
> Cc: [EMAIL PROTECTED]
> Subject: RE: (ROSE) Test scenarios
>
>
> 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)
>
Where do the account id and the amount come from?
Does another use case collect this information, then <<include>> this one?
Parameterised use cases are good for describing actions often used in
different contexts, but this seems like a method to me.
> 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
>
These confirm that the information gets collected outside the use case
scope. In that case, what does the use case describe? I suspect nothing more
than the internal processing. There is a place for this in use cases, but
the user interaction aspect is the most important part of use cases. Without
it, they become program specs. Pseudo-code would do just as well in that
case.
> 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...)
>
How do you do scenarios? Do you document them all individually?
> 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
> *
> *************************************************************************
>
************************************************************************
* 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
*
*************************************************************************
