Automate testing for provisioning policies

IdentityIQ (IIQ) IIQ Show and Tell
, , ,
1

Hi,

We are building a tool to help in the end-to-end testing of your provisioning policies and workflows. The basic idea is to speed up the development process with automated testing.

You can use APIs to perform actions and assertions directly or use the visual builder to build the test. For example, let’s take a very simple joiner scenario –

When an employee joins the org, a new entry is created in the HCM system. Assert that when this happens, the user gets an IdentityIQ and Active Directory account. So, to test this scenario, you would do the following –

  1. Add a record to a CSV file (local or remote)
  2. Wait for N seconds for the account to be created in the HCM system.
  3. Trigger a single application aggregation in IIQ.
  4. Wait for IIQ aggregation task completion or M second timeout.
  5. Verify that Identity exists in IIQ with a specific attribute(s).
  6. Verify an account existing in AD with a set of attributes.

We would love to hear your feedback, thoughts, and experiences with testing your policies and workflows.

Some screenshots of the visual builder -

Compose_ Suite
Compose_ Suite1440×907 45 KB

Compose_Test
Compose_Test1440×907 121 KB

Compose_ Block
Compose_ Block1440×907 66.2 KB

2

Thanks for sharing, it seems to be really good way to automate the testing. My two cents on the topic as I have been a part of few implementations where we built similar solutions:

  1. Workflows generally have steps with wait and split provisioning and approvals, with APIs we can submit a request and may be poll to see the current state of the workflow but to get the exact issue (if any) the developer/tester have to login to the IIQ environment and validate the Task Results etc. Try to add details about the what went wrong with the test case with the details about what caused the issue and which step failed.
  2. The test cases may include various steps like process approvals, validate emails and re-run the scenarios with all possible test cases (where we could test with different parameters also can add/skip few steps in the workflow), so if your solution provides a way to feed these inputs in a way the developer/tester can create the test cases separately and your solution will be able to get the steps and inputs and run the test cases.
1 Like
3

Workflow state can be obtained more easily by launching Workflow and getting the session.
And then it is possible to do different things with the workflow in hand. Check its state, fill in forms, advance to steps etc.
For example below. And then there is also a WorkflowTestSuite

WorkflowLaunch wfl = new WorkflowLaunch();
wfl.setWorkflowRef("TEST THIS WORKFLOW");
wfl.setCaseName("TEST");
Attributes vars = new Attributes();
vars.put("variable","value");
vars.put("foregroundProvisioning", "true");
wfl.setVariables(vars);
wfl.setSessionOwner("spadmin");

Workflower wf = new Workflower(_context);
WorkflowSession ses = wf.launchSession(wfl);
assertNotNull(ses, "No workflow session created");

checkTestFile("/workflowSessionExpected1.xml", ses.toXml());

WorkItem item = ses.getWorkItem();
if (item == null)
    throw new GeneralException("Synchronous work item not found");

Form form = item.getForm();
if (form == null)
    throw new GeneralException("Synchronous form item not found");

// simulate the rendering of the form and the assimilation of post data
Field f = form.getField("Resource With Template 2:accountId");
f.setValue("test1");
f = form.getField("Resource With Template 2:firstname");
f.setValue("test2");
f = form.getField("Resource With Template 2:lastname");
f.setValue("test3");
f = form.getField("Resource With Template 2:location");
f.setValue("test4");