I recently posted on how BA's can use Enterprise Architect to document the requirements of a system. This time round it's the Testers turn. If you're evaluating EA from a Tester's point of view this post contains a few things to consider. I should say from the outset - I am not a Tester. I do know what features are in EA to support the testing process. If I misrepresent you Testers out there - apologies :-)

Compared with how EA supports BA's and Software Architects, I'm afraid the news isn't quite so good for the QA team. If you're expecting functionality along the lines of FogBugz then you're going to be disappointed. 

Traceability

One of the biggest benefits for testers is the ability to trace test cases back to the actual design elements that are being built. In this manner you can verify that you have an appropriate level of test coverage that is difficult if your test cases are in separate documents not linked in any way to the actual requirements of the system.

EA essentially provides a means of managing "things" (actors, use cases, requirements, components, classes...) and the relationships between them (associations, realisations, generalisations...). In UML speak the "things" are referred to as elements. Consider the following diagram which shows the relationships between an Actor and some Use Cases. Relationships are also defined where one Use Case extends another.

image

Testers can then create Test Cases against any element (although most frequently against Use Cases and Requirements). For example, if you were to select the Close Account use case in the above diagram you would see the following details in the Testing tab (this is taken from the example project that comes with EA 7.1).

 image

You set the description of the test case (which in this case is imported from the scenarios of the use case itself) and report inputs, acceptance criteria and results.

Test Cases come in four flavours,

  • Unit - for things that are being built, such as Classes and components
  • Integration - to test how components work together
  • System - to ensure the system meets business requirements
  • Acceptance - to test user satisfaction, and
  • Scenario - to test the end-to-end suitability and functionality of the application.

The details for each type of test are almost identical so I'm not quite sure why they separated them out over separate tabs. I would rather have seen the a type field against a generic test case.

At this stage it's pretty clear that if your analysts aren't using EA then you're not going to get much joy out of using it to manage your test cases.

EA is not a stand-alone software testing tool; if your analysts aren't using EA to model Use Cases and Requirements then EA is not the tool for you.

Documentation

As with most other areas of EA you get documentation for free. Simply select to create the Test Report and you get something like this.

image

More advanced documents can be produced using the RTF documentation features. You can also manage all the test cases in your project from a simple Test Details dialog.

image 

Changes, Issues and Defects

In addition to test cases EA supports elements to identify Changes, Issues and Defects. These elements can have relationships to the elements they refer to in order to track activity around them. To be honest I can't see anyone using these elements to track issues and the like. There are far better products to do this elsewhere. In particular you can't track a history of comments/activity against an Issue (or Defect, or Change). The properties for these elements are fairly sparse.

image 

And that's about it for Testers using Enterprise Architect. I'd be keen to hear from anyone who is using EA in earnest for Testing - is it working for you?