Linking User Stories to Test Cases

When creating Test Cases within a Test Panel Suite, it is important to be able to relate each test case to an Objective, or "User Story" in Agile parlance.  In Identity Panel these objectives are simply created as tags which can then be used for Reporting on Test Coverage.

However, the Objectives themselves still need to be articulated, and one of the most effective platforms for doing this for an Identity Panel implementation is DevOps Solutions | Microsoft Azure in which to create Azure Test Plans | Microsoft Azure.

While not every customer will necessarily be licensed to use DevOps, SoftwareIDM provides this guidance for those that do.  For those who choose an alternative format, whether an organized collection of documents or a proprietary solution, this guidance is designed to assist you in organizing your thoughts around your own methodology.

No set of Test Cases is truly effective unless it can be directly tied back to one (or more) objectives.

Creating DevOps Work Items

A dedicated DevOps project should first be created for your Identity Panel instance licensed for Test Panel.  All Identity Panel Test Cases within each Test Suite should be found within the same project.

Work Items are created in one of the following categories within a DevOps project:

For the purposes of this guidance, we will focus on the following subset only, which form nodes in your Test Plan hierarchy, whereby each parent node has one or more child nodes:

• Epic - the top level, e.g. a cohort of identities such as HR Users
  • Feature - a requirements category, e.g. "New Starter" (in a JML context)
    • User Story - an expected category outcome, e.g. "New Starter - AD Account Created"
      • Test Case - each outcome variation, e.g. "new employee" or "returning employee"

Once created your DevOps "Board" page will look something like the following (with the selected "Epics" focus):

In the SIDM model, only the User Story has any level of detail, with Epic and Feature levels providing structure only.  In the above example, the User Story might look something like this:

Note that while the Test Cases within the above User Story appear as links under Related Work on the right, there is no need to elaborate on each Test Case itself - the detail is defined within the Identity Panel Test Cases and can be extracted directly from the inline As-Built document.

The detail from the above example is provided below to assist you in your own setup:

By following the above model, each Test Case can be tied back to a User Story (grouped by Epic/Feature) - making the User Story name/identifier an ideal "objective" tag in Test Panel, as this then provides strong correlation to each Test Plan in your Test Suite.

Tagging

The use of DevOps tags is crucial in providing alignment between each Test Case within each Test Suite, and in this way it is possible to construct DevOps Test Suites to match the Test Panel Test Suites using the same names.  These are the same tags that should also be used as Objectives within Test Panel.

In the above example I have used the following tags for each of the 4 levels:

• Test Panel (to differentiate these tags from any other DevOps tags that may be in use)
• HR and JML (to align with the Epic)
• New Starter (to align with the Feature)

This will then allow me to define Build and test integration queries - Azure DevOps | Microsoft Learn which can then be matched to the ones in Test Panel of the same name.

Test Suites

Test Suites, whether defined in DevOps or Test Panel, are structured collections of Test Cases designed to correlate to defined business Objectives (User Stories). By careful use of tagging, we can

• Define each Test Suite in DevOps as queries against a collection of DevOps Test Cases
• Determine Test Case coverage by Reporting on Test Coverage in Identity Panel

The above tags are suggestions only - you will need to define your own set to ensure Test Coverage.