Book a Demo

Author Topic: Suggestions for Tracing Test Cases to UC Scenarios  (Read 2968 times)

genesis10jeff

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Suggestions for Tracing Test Cases to UC Scenarios
« on: June 16, 2005, 11:12:41 am »
We are following traditional documentation for building Use Cases (Basic Flow, Alternate Flows, Exception Flows), tracing our SuppSpecs, Business Rules, etc. to the Use Case.

Our Test team would like to trace their test cases to our Use Case SCENARIOS (by each flow pattern possibility), not just the Use Case by itself.

Does anyone have experience with this that could share any suggestions?

A VERY nice to have for us would be the ability to customize attributes on the Use Case to track which portion(s) have been tested and passed or failed.  We don't have any ideas how to do this, but will track that information on the Test Case instead and generate some complex reports to determine how far through our Use Case Model we have tested.  Any ideas on this subject are welcome as well.

Thanks in advance!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Suggestions for Tracing Test Cases to UC Scena
« Reply #1 on: June 16, 2005, 11:54:06 am »
Quote
We are following traditional documentation for building Use Cases (Basic Flow, Alternate Flows, Exception Flows), tracing our SuppSpecs, Business Rules, etc. to the Use Case.

Our Test team would like to trace their test cases to our Use Case SCENARIOS (by each flow pattern possibility), not just the Use Case by itself.

Does anyone have experience with this that could share any suggestions?

A VERY nice to have for us would be the ability to customize attributes on the Use Case to track which portion(s) have been tested and passed or failed.  We don't have any ideas how to do this, but will track that information on the Test Case instead and generate some complex reports to determine how far through our Use Case Model we have tested.  Any ideas on this subject are welcome as well.

Thanks in advance!
Hi Jeff?,
My suggestion involves a bit of work, but could ultimately pay dividends.

I would:
1)    Attach an activity diagram to the Use Case,
2)    The diagram activities would correspond to the steps in the use case (perhaps with appropriate stereotypes «user», «system»
3)    Create partitions for each flow and place the activity inside the appropriate partition (just for completeness I'd place a nesting link between the activity and the partition - that way, you can formally relate the two  so automation could traverse)
4)    Add the test cases to the diagram
5)    Link using the trace dependency to the appropriate partition
6)    Use the target role to show the status (say Untested/Tested)

Voila!  A visual representation of the Use Case with Test Case traceability... 8)  One can conceive of some automation that would traverse this diagram and actually generate the Use Case text for the higher level Use Case!  8) 8)

You could add using and extending use cases (if required - at the appropriate points (activities)).

HTH,

Paolo

Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Suggestions for Tracing Test Cases to UC Scena
« Reply #2 on: June 16, 2005, 04:04:16 pm »
I have a similar problem with the test to requirement direct trace.

The way I'm doing it involves a violent hack into the EA database, use of Sparx fields that are not being used, addition of extension and association tables and an add-in that has been slowly evolving over the last 6 months.

The problem is that t_object relates ona one to many basis to both t_objecttest and t_objectrequirement (in your case t_objectscenarios).  Thus, although Paolo's suggestion may work in simple situations, when you get to test cases that attend to >1 scenario and v.v. you'll run into problems.

Good luck!

bruce
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Suggestions for Tracing Test Cases to UC Scena
« Reply #3 on: June 16, 2005, 07:11:24 pm »
Quote
[SNIP]
The problem is that t_object relates on a one to many basis to both t_objecttest and t_objectrequirement (in your case t_objectscenarios).  Thus, although Paolo's suggestion may work in simple situations, when you get to test cases that attend to >1 scenario and v.v. you'll run into problems.

Good luck!

bruce
Clarification:  When I said link Test Case, I meant using a Test Case object, not the "element based Test Case".  Also, I used the partition to define the scenario since although EA provides the concept of a scenario on a per-element basis, it doesn't provide a global one (as it does with Test Case).  Orthogonality, orthogonality, orthogonalityTM

bruce (as usual) is perfectly right regarding the use of the "internal" versions of these concepts and the one-to-many relationships.  Hence my usual avoidance.

Perhaps, if we asked nicely, the Sparxians would provide a fix for this.  Personally, I would never have built any of these element based concepts as one-to-many.  In the real world, they are really many-to-many (as evidenced by the kinds of "hacks" bruce has had to make).  To me it's a rendering problem.  If I say add a Test Case to this element, I mean create a (global)Test Case and link it to this element.  that way If I need to use it elsewhere, I can use the create link functionality to link another element to the existing case.

bruce, given my clarification, will this not work - in the general case?  I'm interested as I intended to go down this path myself in the not too distant future, but if there's a fundamental flaw in it, I'd rather fix it now than refactor later...

Thoughts anyone?

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Suggestions for Tracing Test Cases to UC Scena
« Reply #4 on: June 16, 2005, 07:40:36 pm »
Quote
bruce, given my clarification, will this not work - in the general case?  I'm interested as I intended to go down this path myself in the not too distant future, but if there's a fundamental flaw in it, I'd rather fix it now than refactor later...


I did not go down this route because of the following:

1) I did investigate it - but only to the level of a thought experiment.  Solution was disregarded because under the hood it adds another level of indirection in the t_object domain.  Too easy to create problems unless proper usage rigidly adhere to by the modeller (who is not known globally for sticking to his own edicts of convention).

2) I, personally, dislike the externalised feature approach - except for requirements - (hows that for consistency!) tests, changes etc relate, on my planet, to one and only one object, ever, ever (unless I change my mind later).

So, I can't really comment on the viability of your approach from a considered pov.

3) Also, the hacks I mention were born of necessity, not design.  I have no intention of stabilising them - the project finishes in Octember (according to the plan!) at which time the EA repository will be shredded.

bruce
« Last Edit: June 16, 2005, 07:41:28 pm by sargasso »
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.