Reputation: 1
I'm looking to migrate legacy text-based test plans/results from DOORs into MagicDraw and display them in a table, but I'm struggling with how to enforce the ordering, while still making it easy insert new test steps in the future. The current tests in DOORS are organized into sections, so I have a custom TestSection and TestStep stereotype in MagicDraw. TestSection owns 1+ TestSteps. I have both shown in a Generic table, and the TestSection can be expanded/collapsed to show the test steps for that section.
Here's an example of what I'm trying to end up with
In most cases, the tests were written with the expectation of them being executed sequentially, so if "Test 2" ran before "Test 1", it would fail. If we merged them together so they couldn't be out of order, we'd lose traceability resolution back to requirements.
Some things I've tried: Reordering in a table is easy with the "Move Row Up" and "Move Row Down" buttons, so this is definitely my preferred approach, but if you accidentally click any column header, you will lose your test plan ordering. This sorting is also unique to that table, so if you want 2 tables (one for just a section, and one for the entire test plan), you will have to manually sort the steps in both. Being limited to a single table is an ok limitation, if there is a way to disable sorting by clicking the column headers. I've been looking through the table settings/specifications/customizations and do not see anything.
I tried creating a property within the TestSection stereotype that contains the list of TestStep items, and these can be ordered, but that still doesn't enforce any kind of ordering in the tables, unless you just show TestSection items, and use a bunch of custom columns and metachain navigations to extract the steps. This ends up being pretty unusable, since you get a bunch of test steps munged together into a single row, and you can't work with the test step data directly in the table.
I'm currently using the auto numbering customization to generate unique test ID's. And I considered creating another attribute to number the test steps, then use the column sorting in the table to sort them, but that seems pretty clunky for inserting new tests in the middle.
Sequence or activity diagrams with control flows are probably a more proper way to capture the test ordering, but building extra diagrams wastes a lot of time and there does not appear to be a straightforward way to pull that back into table format that is concise for testers to step through.
Upvotes: 0
Views: 109
Reputation: 11719
You could use a dependency link or create a custom stereotype based on dependency (i.e. Test Case Dependency, etc.), and then link from a test case to another that is a dependency for it (point toward the item that is the dependency).
This would allow you to create derived properties or a custom column in a table that show the dependencies.
This won't automatically sort them for you to order the test cases correctly.
Another option would be to separate your test cases, which describe the scope of the test (what needs to be tested) from the test procedures. It sounds like what you have in DOORS is really test procedures, not test cases, which can be separated to be more high level and describe WHAT to test, not HOW to test it (similar to how requirements should typically describe what is required, not how to implement it).
Then create a custom property for the Test Cases (as a new custom stereotype) that has an array of the test procedures that carry out that test case.
That makes the test procedures reusable and allows you to specify an order to them. You could couple this with the dependency relationship idea above or something similar to build known groups or series of test procedure blocks that go together.
Upvotes: 0