2

I'll express my doubt with an example. Suppose I have the following requirement:

The customer needs a page in his website that displays all the products he has with a quantity field on the side of each product. The visitor of the website must be able to fill in the quantities desired, select one location and ask for the budgeting. After asking for the budgeting, the visitor must be taken to a page with the summary of the products asked, together with the prices and fields to fill in contact informations to proceed the negotiation if desired

To organize this I've decided on building two use cases: "Require budgeting" and "Ask for products". The first one is:

Title: Require budgeting

Actor: Website visitor

Scenario:

  • The visitor selects to see the products

  • While the visitor want to add products to the budgeting

    • The visitor fills the desired quantity of a product in the corresponding field
  • The visitor selects his location to estimate shipping price

  • The visitor sends the requirement

After that, the visitor will be redirected to the page with the information about what he asks and the fields to require the products. This is another use case, but there is a close connection with the first one, because it is in the sequnce. I didn't know exactly how to deal with this. So I thought of using precondition:

Title: Ask for products

Actor: Website visitor

Precondition: the visitor has asked for a budgeting

Scenario:

  • The visitor reviews the products and prices

  • If he wants to ask for the products

    • The visitor fills his contact information and sends to the sales department
  • If not, he exits the page

But I'm unsure this is the right way to do so, I think that "extension" was the right way to express that, but I think I didn't get this yet.

How should we proceed when use cases are closely related like that?

1

The way I see it, you can argue two 'right' ways of doing this: A) the whole thing is one large use case (primarily considering the 'ask for products' case to be the dominant one you're writing for), or B) the way you've got set up, where you have a short case for each atomic action (requiring budgeting, asking for products), and specifying a precondition where necessary (asking for products requires that budgeting already exists, which requires other stuff, etc.)

If I had to implement this using something like SpecFlow, keeping it the way you've posted is beneficial because I can do something like this:

Given the user has added budgeting
And the user views Review Products & Pricing
When the user enters their contact information
Then a request is sent to the sales department

...The first given step would likely be a call-forward macro for that first story, whcih would probably be written as such:

Given the user views Manage Budgeting
When the user requests Item [X] in Quantity [Y]
Then the requirement is saved

The ability to do it like this, in my opinion validates how you organized these two related test cases.

  • I agree with Andrew. However, I'd argue that you all should just use Gherkin (SpecFlow) to specify your use cases in the first place (rather than specifying them at this high level and then leaving that open to interpretation). What the OP provided above would go in the "Feature" section of a Gherkin requirement, and would get elaborated by the dev team or a detailed requirements person into the scenarios Andrew explained. Then everybody's on the same page, and "making sure you're writing the requirement the right way" is less important. Right is whatever gets everybody on the same page. – Calphool Apr 17 '14 at 20:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.