FYI
-----Original Message-----
From: Jason Gorman [mailto:[EMAIL PROTECTED]]
Sent: 15 February 2001 16:33
To: Angay, Huseyin (Huseyin)** CTR **
Subject: RE: (ROSE) Test scenarios
Hi
Which "spirit" of use cases is this? Rigour is *always* a good thing.
Remember, this is software *engineering*! Look at cleanroom or catalysis. If
you want high quality software then I recommend this approach.
Inputs to use cases are implicitly supplied by the actor(s), as they are the
external client. You do not need another use case purely for collecting
inputs, and the physical manner in which inputs are collected is not part of
the use case (eg, by form, by fax, by carrier pigeon...) The use case is
logically the same in all respects. If it is not then there is something
wrong with the use case.
You can use storyboarding to describe UI interactions, and append this to
the use case, but it is not the point of the use case. I would avoid the
complexities of use case models (<<includes>>, <<extends>> etc etc) because
the metamodel is vague and disjoint with the rest of UML. Far too much time
is being spent arguing about use cases. We need a much simpler and more
precise metamodel.
Cheers
Jason
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Angay, Huseyin
(Huseyin)** CTR **
Sent: 15 February 2001 14:42
To: '[EMAIL PROTECTED]'
Subject: RE: (ROSE) Test scenarios
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
*
*************************************************************************
************************************************************************
* 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
*
*************************************************************************
