Test Case element

[thomaskilian]

Hi there,
can anybody explain me the use of Test Case elements (found in the custom toolbox)?

Additionally: why is it possible to attach attributes and operations to Test Cases? Looks strange since they resemble to use cases.

[mikewhit]

In EAExample they appear to be stereotyped Use Cases, so presumably are testing scenarios that may be applied to test other elements.

There's also (somewhere) a UML Test Profile, but that seemed specifically for describing tests in endless detail.

[thomaskilian]

Hi Mike,
stereotype use cases - it seems to make sense, yes. But there's also the Test Cases tab with lots of scenarios you can import from Use Case scenarios. Now where to use what? Any practical experience out there?

[mikewhit]

As you know ;-) the only part of EA I grumble about is Testing (/Requirements).

The Test Case stereotypes can exist on a diagram, and can be linked to elements, whereas the Test Cases window stuff is associated with one diagram element only, and is 'hidden' within that element.

I think Tests really need to reside in a kind of parallel universe so they don't 'live' on a UML diagram, but with links to elements or packages as required to indicate coverage. Same goes for Requirements.

But also need a Matrix/coverage viewpoint to allow every Requirement to be Realised, every element to be Tested, and every Requirement to be Verified by a Test.

In my project, I have gone through all Activity diagrams and added Test Cases (Testing window) to every activity element, listing all possible cases at each point (eg. valid input case 1...n, invalid case 1...n, null input ...).

Then the Test people made a report of the test cases, and strung them together in meaningful sequences to make proper tests.

But it's far from ideal, and gives you no overview.

[sargasso]

What he (Mike) said * 10!  

Thomas, I am currently doing a test design for an online booking engine - pretty simple - 21 use cases, 386 tests aligned to the use cases represented as tests within the use cases ..........

..... and one test case element - which I have had to use because the test does not align to a use case.

This is the only place I have found a use for them.   As Mike said, test cases and internal requirements inhabit a paralell universe and to really use them well you are continually forced to automation or to using Access.  I have an Access app that links the relevant tables in the reppository and use it to produce the reports (test status, scripts, schedules etc) that are needed.

hth
Bruce

p.s. in case you're wondering - the odd one is a test for proper behaviour of the web server when the app server or the back end res system is unreachable.

[thomaskilian]

Mike an Bruce,
thanks for you feedback. So I understand right that Test Cases can be used for "Meta Use Cases" which exist but do not appear in the Use Cases but only in certain testing environment? Sounds strange and I'll like have to deal with it in a real live example (in my world).

Still a lot to learn

(Bruce: EA fenestrae sublicit!)

[mikewhit]

... but do not appear in the Use Cases but only in certain testing environment...

No, not quite.

I only meant that Tests and Requirements ought to exist in a parallel world to the UML (sort of like a Photoshop layer), not that EA actually did that.

The stereotype Test Cases are normal diagram elements.

Have a look in the EAExample.eap model e.g.
- Messenger - Model Views - Test Model - Unit Test Model - Message

[thomaskilian]

Just had a look and I don't see why one should work like that. Wouldn't you select Message and place the test cases inside the Test Cases window (as unit test)? Why should one place these elements additionally on a diagram?

[mikewhit]

Well this brings up the whole issue that bothers me.

Using test case elements gives 'visibility' to the testing, and also allows you to model the tests using the same UML notation.

But yes, I think it's a bit of a mess.

[thomaskilian]

The same applies to Issues where you have a table and also Issue elements. Here I decided to use the elements (for being able to make use of tags) whilst the test seem to be better placed in the table (because you can import scenarios to be converted to tests).  It links with this thread: http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=suggestions;action=display;num=1101322647

[mbc]

The Unified Process defines a Test Case stereotype which is applicable to Use Cases and looks like the test case element in EA. I guess that is where it comes from.

Personally, I like to be able to draw my test cases. As much testing as possible should be done automatically and therefore often require both programming and design. A test case element is useful for showing relationships (what is it testing, which requirements is it verifying, which test class(es) implement the test, etc.). Furthermore it is useful for grouping related information in the project tree, e.g. diagrams describing the test.

I would like the test case element to somehow be integrated with the EA test management system, so that they would appear in the lists.

Mikkel

[mikewhit]

The only trouble is that if the Test Cases appear on the model diagrams, they distract from the model itself, hence my comment about them being 'in parallel' with the model rather than part of it.

[mbc]

No, I wouldn't put the test cases on my normal class diagrams etc.

The test cases go on separate diagrams in the test model part of my EA model.

Mikkel