Example Configuration

Below is a sample Configuration for Service Validation and Testing

To implement Service Validation and Testing, you will need to plan out your program. It is perhaps best to start with a checklist and then compare that against what you already have In ASM. Below is the configuration that was placed in the product for ITIL V4 compliance. It may not all work for your organization and that is OK! Pull from it what is useful.

Part 1: Planning Checklist

What are your Test Phases?
What Testing will be automated? Does the automated testing tool accept transactions from ASM and can it pass data back to ASM?
Will you test in Cycles or Sprints? What methodology will you use?
Who is on the test team?
Who has Go-No Go authority?
What data is required in each test plan - the standard data that is repeatable across all tests? This is information we can collect on the screens and validate.
What Data is required for the defect log and will you want to automate sending these defects to another system such as Jira?

Part 2: System Administration Settings to Support Testing and Validation

Once you have roughed in a plan for all the specific information you need for your testing strategy, its time to set the system up to accomodate it. In our test system, we updated the following:

CMDB Item Types. We added CMDB Item types for Release, Release Candidates, Stubs, and Drivers, and for Payload and Payload Elements. We also added a CMDB Item type for Requirements. This is critical since you can then link tests directly to individual requirements along with any defects found against them.
In Workflow Management, we created the request screen sets for each kind of test, Functional and non functional along with a screen set for the Test Planning Strategy. In essence, we configured our system so that a test strategy for each cycle is submitted and in that strategy all the various kinds of tests that are desired are selected. Similar to placing an order. Upon submission and approval of the strategy, ASM automatically generates the requisite requests as separate workflows. We did this so that if the testing parameters or processes for an individual kind of test, Performance testing, for example changed, it would not impact any other testing processes or automations for that particular release candidate.
We also set up the request, or testing, phases in workflow management.

Part 3: Screens to Support Testing and Validation

After you have configured your system, you can begin building your screens to support your test strategy. The basic elements are provided, but using Designer, you can fit them to your organization, specifically.

Part 4: Workflows to Support Testing and Validation

Several workflows are already configured to support Service Validation and testing, but you will need to visit each one and alter it to suit your organization and your potential integrations.

Part 5: Configuring your Defect Registry and RAID logs

Following along from screens and System Settings above, if you will track defects in ASM, you will need to configure a screen to do so. These need not be complicated. Since the CMDB is tracking Releases, Candidates, Requirements, etc., you can easily use any existing IPK Screen you may have configured and log the ticket against the CI(s) and select the correct Testing Type tier to go with it. These data are then easily passed to any other external system you may be using.

For example, the following type tiers are suggested:

Testing>Defect
Testing>Failure Event
Testing>Progression/Regression Threat
Testing>RAID Log item
Testing>Security Issue

Part 6: Integrations and Automations

Planning for your integrations and automation is likely the most extensive part of work you will have when decididing to implement your testing and service validation strategy. Familiarise yourself with the R estFul API, and then as above, make a plan for the data that will passed to and from ASM.