Modelling testcases in UML

[Geert Bellekens]

Bruce,

Thanks for your input, but I think we are talking about something differently.
The TestCases I wish to describe are automated "regression" tests that will be developed just like any other functionality of the system. Therefore I believe they have their place in the EA/UML model.
For our purpose I need to have a good overview of which tests are implemented so that our functional analysts know which parts of the system are covered by automated regression tests. And more importantly which parts aren't.

Geert

[Paolo F Cantoni]

Hi bruce,

If Scenarios were behavioural features of a Use Case, which I believe wouldn't be prohibited by the current UML 2.2. specs.  Then you could use the Link to Element Feature functionality to link a test case to a specific scenario.

Thoughts?

Unfortunately, I don't think Sparx would contemplate such a change.

As an interim cheat, you could create "operations" with the same name as the scenarios and do it "indirectly".

Paolo

[son-of-sargasso]

Thoughts?

I like it!  Its quick, has a lot of visual power.  It "contains" the test cases within the use case...

What do you think Geert?

[Paolo F Cantoni]

[size=18]...[/size]
I like it!  Its quick, has a lot of visual power.  It "contains" the test cases within the use case...
[size=18]...[/size]

Thought you would!  

One cool feature for me is that I can interrogate the model to find the linkages .

I presume you intend to document them there (in the operations) - and pretty much ignore the Scenario tab of the element itself.

The better solution, of course would be for scenarios to be added to the list of things you can attach the
"Connect to Element Feature" to, add them to the things you can render in compartments (via Feature Visibility [Ctrl+Shift+Y]) and visually show the linkage directly - more or less as in your diagrams above.

Paolo

[son-of-sargasso]

One cool feature for me is that I can interrogate the model to find the linkages .

Yep, it sure does.  

I presume you intend to document them there (in the operations) - and pretty much ignore the Scenario tab of the element itself.

Actually I was thinking of thinking about using a transform or something to copy/sync the two.  

The better solution, of course would be for scenarios to be added to the list of things you can attach the
"Connect to Element Feature" to, add them to the things you can render in compartments (via Feature Visibility [Ctrl+Shift+Y]) and visually show the linkage directly - more or less as in your diagrams above.

Definitely, maybe that's a Suggest - I'll get back to it later, I've really got to spray these fruit trees TODAY and I'm just using this as a procrastination crutch atm.  

bruce

Edit: It also gives me a good hook to synch my system with EA, something that I could only do via the usecase ID before, which had some issues.

[Paolo F Cantoni]

[size=18]...[/size]
Actually I was thinking of thinking about using a transform or something to copy/sync the two.
[size=18]...[/size]

Yes, that was an alliterative I also considered - since there's not much metadata involved, shouldn't be too hard...

Take care,
Paolo

[Geert Bellekens]

Bruce,

Shouldn't those <<trace>> dependencies by directed in the other way?
I see Testcases to be dependent on UseCase(s)(Scenarios), not the other way around.

Geert

[son-of-sargasso]

Geert,

You are correct.  I was mucking around at the time I took the screenshot to see what was the "best" effect in the Relationship Matrix and Dependency Report and wasn't paying to much attention to semantic correctness at the time.  I'm not even sure that <<trace>> is the "most correctest" dependency type, it was just handy.

OTOH, a correct implementation of Usecase 2 depends on the correct implementation (i.e. test success) of all the TC's    Given my current confusion over directionality, I'll leave it up to you and whats-his-name to decide.  8-)

bruce

  

[Geert Bellekens]

Bruce,

You have said it correctly, the "implementation" might depend on the testcases, but not the usecase itself.

I think it is actually pretty easy to decide on the direction of the dependency. Just ask yourself is A going to (or might to) change if B is changed.
In this case obviously Testcases will change if the usecase changes, the usecase will not need to change if a testcase is changed.

Geert

PS. I'm not entirely sure if your joking about the directionality, I thought I'd write it up anyway. I'm not trying to insult you :-/

[Paolo F Cantoni]

PS. I'm not entirely sure if your joking about the directionality, I thought I'd write it up anyway. I'm not trying to insult you :-/

Well you Belgians have developed a reputation here...  

BTW: bruce likes his name spelt "bruce".  Many years ago (now) I changed my spell checker so it would allow "bruce".

Also, I think "what's-his-name" would agree with you on directionality - though I may be putting words into his mouth...  

I'm going on a couple of weeks leave "down south" here in WA so I may be off the air... (or I may not - depends on connectivity).  When you've got a state three+ times the size of Texas with only just over 1M people 95% of whom are in Perth (and just over 23M in the whole nation, the size of the continental US), it's sometimes difficult to justify connectivity for ALL the carriers everywhere...

[Paolo F Cantoni]

I like it!  Its quick, has a lot of visual power.  It "contains" the test cases within the use case...

So you'll be putting in the feature request?

Paolo

[bnils]

Modelling test cases based on scenarios of use cases is supported buy the tool. But is there any way to create scenarios from Requirement-elements? Yes, the transformation requirement -> use case -> scenario -> test case is the obious case but Im investigating the possibilities to create test cases directly from requirements. Any ideas?