Best UC method you\'ve encountered
Since I've been a software tester for a number of years I've encountered better and worse requirements/UC. The thing is that I'm now entering the world of writing the damn things myself. There are already existing UC so I'm not beginning from scratch, but I sincerely doubt that they are written in the best way possible and I'm thinking about taking a course in writing UC. I therefor want to know if you've read a UC that you just went "Oh, my God, this is soooo good" so you can give me any good tips on which method to start using that will fit my purposes...
The system I'm working on is quite complex (a retail system) and what bugs me is
a)there is no flow charts which I think is a great visual help
b)I find that the number of levels of subchapters are quite scary
c)too much repetition when you should be able to just point out a different UC that handles that specific flow.
All UC method tips will be appreciated. Thanks.
Re: Best UC method you\'ve encountered
We use an Agile software development approach where I work and we have a single rule about our marketing/development/test requirements (called user stories in eXtreme Programming).
INVEST in your user stories.
They should be:
If an individual use case doesn't fit into the above (and I mean _ALL_ of the above), we rewrite it.
I don't tend to worry about the huge requirements documents and huge list of test cases/plans. We use our story cards to create the software and to run the tests. We write the cards with our customers in mind and our marketing folks in the room with us so everyone has a stake in making the software the best that it can be.
We also leave the stories somewhat open ended. I don't write the traditional 20 steps to test a feature type test cases. I write that, "as a used of the software, I want to add a customer to our list of existing customers and I want to capture their current purchase information at the same time."
You'll notice there are no technical handcuffs, no testing roadblocks setup, just what the software should do and the expected result. They we break those stories down into the actual task cards and focus on the technical details like which DB server to use, how long a transaction should take, how much information about the customer needs to be stored, are there any mandatory fields, etc.
Each of those tasks becomes a test.
But I should never have to write out step by step how to determine if enough data is stored in the DB, or if the user's name is valid.
and once you have those cards written, you just copy/paste them into the huge document that the corporation requires you to keep. [img]/images/graemlins/smile.gif[/img]
Remember: if it's over 6 pages, no one will read it... and if it's less than 2 inches thick, it's too light to hold open my door.