Home > Archive > Extreme Programming > March 2005 > How to organize artifacts? (Use Cases, Acceptance Tests, etc)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to organize artifacts? (Use Cases, Acceptance Tests, etc)
|
|
|
| Hello, I would like some recommendations on organizing
documentation/artifacts and referencing them in code/unit
tests/acceptance tests. I am trying to incorporate UP and XP
practices into my work, and am having trouble keeping track of
requirements and showing how the code and tests are covering the
requirements.
For example, suppose I have 10 Use Cases, each of which has 3 possible
scenarios besides the "happy path / everything OK" scenario. Some of
these may require system sequence diagrams (as discussed by Larman in
"Applying UML and Patterns") and other sequence diagrams, just for the
developers' understanding. There may be pre- and post-conditions for
some of the Use Cases, etc. When creating an Acceptance Test (which
presents the ultimate picture to the client whether the thing's doing
what they want it to do or not), do you use a reference number code to
show which Use Case and Scenario the test covers? E.g., do you
include a comment that says,
Acceptance test: AT42
Related to Use Case: UC13
Checks Contract: UCon10
And is there a way to show that the various use cases and contracts
have been covered in the Acceptance Tests? E.g.:
{Use Case/Scenario (Contract): covered by Acceptance Test}
{UC1 (UCon1): AT1, AT2, AT3}
{UC1/A: AT4}
{UC1/B: AT5}
....
{UC10/C: AT53}
I'd be interested in hearing how people manage their tests and
artifacts, and ensure that things don't slip through the cracks.
Jeff
| |
| John Roth 2005-03-13, 3:57 am |
| "Jeff" <jeffz_2002@yahoo.com> wrote in message
news:7b01eaf3.0503121645.7b2f780e@posting.google.com...
> Hello, I would like some recommendations on organizing
> documentation/artifacts and referencing them in code/unit
> tests/acceptance tests. I am trying to incorporate UP and XP
> practices into my work, and am having trouble keeping track of
> requirements and showing how the code and tests are covering the
> requirements.
>
> For example, suppose I have 10 Use Cases, each of which has 3 possible
> scenarios besides the "happy path / everything OK" scenario. Some of
> these may require system sequence diagrams (as discussed by Larman in
> "Applying UML and Patterns") and other sequence diagrams, just for the
> developers' understanding.
I'd question the need for sequence diagrams; that smells like
large scale upfront design. That level of design is much better
deferred to the developers.
> There may be pre- and post-conditions for
> some of the Use Cases, etc. When creating an Acceptance Test (which
> presents the ultimate picture to the client whether the thing's doing
> what they want it to do or not), do you use a reference number code to
> show which Use Case and Scenario the test covers? E.g., do you
> include a comment that says,
>
> Acceptance test: AT42
> Related to Use Case: UC13
> Checks Contract: UCon10
I'm assuming you're using FIT/FitNesse, otherwise this answer
isn't going to make much sense.
If you need to do that level of crossreference, I'd put the reference
numbers
in a "bureaucracy fixture" and have it slam them into the summary.
Then I'd have the runner put the summary out with the rest of the
run statistics. FitNesse puts out a rudimentary stats xml file at the
moment, and I've just talked to Micah about including the summary
information in it. Dumping run stats out of the batch runners isn't the
hardest job in the world either.
Preconditions are essentially the same thing: you make them explicit
in a fixture of some kind. The same is true for postconditions. The
only issue is labeling them explicitly to tie them back to the use
case precondition and guarantee (or postcondition).
> And is there a way to show that the various use cases and contracts
> have been covered in the Acceptance Tests? E.g.:
>
> {Use Case/Scenario (Contract): covered by Acceptance Test}
> {UC1 (UCon1): AT1, AT2, AT3}
> {UC1/A: AT4}
> {UC1/B: AT5}
> ...
> {UC10/C: AT53}
At the moment, that's basically going to be a manual effort
at creating a traceability matrix. I do, however, notice something
that could simplify things significantly. Instead of "related to use
case UC10" have it "AT for use case "UC10.1" or something
similar, where the dot numbers are each unique path through
the extensions.
Each acceptance test should be for exactly one path through
one use case.
> I'd be interested in hearing how people manage their tests and
> artifacts, and ensure that things don't slip through the cracks.
>
> Jeff
So would I.
John Roth
|
|
|
|
|