ServiceNow Continual Improvement Management Testing and Acceptance Checklist

A testing and acceptance checklist for Continual Improvement Management sets out the test layers, the entry and exit criteria and the evidence that a go-live decision needs. It is written for the people who configure the process and for the process owners who sign it off.

Test Layers

Unit Testing: test individual components in isolation. Does the improvement proposal form save correctly? Does the approval workflow route to the right person? Does the metrics dashboard pull the right data? Each component should work alone before integrating with others.

Integration Testing: test workflows across components. Create an improvement proposal, route it for approval, mark it as approved, and create a follow-up task. Does the entire flow work without breaks? Do data changes in one step propagate to the next?

User Acceptance Testing: test with real users (process owners, improvement coordinators, stakeholders). Can they navigate the interface? Do they understand the workflows? Does the system behave like they expect? Collect feedback and adjust before go-live.

Performance Testing: test with realistic data volumes. If you expect 500 active improvements at any time, load test with 500 to see if response times are acceptable. If they are not, optimise before go-live.

Entry and Exit Criteria

Entry Criteria: all configuration is complete (improvement templates, approval workflows, metrics defined), test data is loaded, and test users have access. You cannot start testing without these.

Exit Criteria: all unit tests pass, integration tests complete without data loss, user acceptance tests confirm the system is usable, and performance is acceptable under realistic load. Every test layer must pass before moving to the next.

Testing Checklist

Evidence to Keep

Document test results: screenshots of successful tests, error logs from any failures and how they were resolved, user acceptance feedback forms, performance test results showing acceptable response times.

Keep the test environment data as a snapshot. If an issue arises after go-live, you can reproduce it in the test environment to troubleshoot.

Archive all configuration export files (workflow definitions, form layouts, dashboard queries). If you need to rebuild or troubleshoot, these files are your starting point.

Regression Traps and How to Avoid Them

Trap 1: Approval Workflow Breaks After Go-Live. Someone updates a form field, and the workflow that depends on that field breaks. Prevent this: maintain a dependency map showing which workflows depend on which fields. Before changing a field, check the map and notify affected workflow owners.

Trap 2: Metrics Stop Calculating. A script that calculates improvement metrics was working in test but fails in production because the field names are slightly different. Prevent this: keep test data in production format (same field names, same data types) and run final tests in a production-like environment before cutover.

Trap 3: User Access Gets Locked Down. Users cannot access their improvements because role assignments were not migrated. Prevent this: plan role migration explicitly. Test role assignment with real users in the production environment (in a small batch first) before rolling out to all users.

Sign-Off

Get approval from process owner, IT, and key stakeholder before go-live. They confirm: the system works as agreed, data is accurate, and they are ready for users to work in it.

Regression Testing Approach

Test that existing workflows still work after changes. If an improvement workflow is updated, run test cases for each workflow state. This prevents unintended breakage.

Keep old test scripts and test data. Before each new version, run regression tests with the old test suite. This ensures backward compatibility and catches breaking changes early.

Writing acceptance criteria that a process owner will sign

Acceptance criteria written as technical checks can pass while the process still fails in use. A check such as the approval field saves a value is true and tells the owner nothing about whether an approval can be traced to the right person. The better approach is to write each criterion as a business statement, then choose the test method that proves it. Each statement should describe a result someone outside the build team can observe and judge.

Promoting configuration without carrying test data forward

Many defects found after go-live arrive from the promotion path rather than from the design. A form, a workflow or a report built in a development instance is moved to a test instance, and something that depended on local data fails there. Decide the promotion mechanism before the build starts. Application scoping keeps related configuration together, while update sets capture individual changes. Either can work, but mixing them without a rule produces records that exist in one environment and are missing in the next.

Refresh test data from a source that reflects production field values, and list the known differences that remain. A test instance that has only clean, complete records can pass checks that production fails on the first messy import.

Automated checks as a regression net, not as a sign-off

Automated test suites are valuable for repeating the checks that broke before. Build a small set that exercises the workflow states, the approval routing and the benefit calculation, and run it after every promotion. Treat a green run as evidence that the earlier behavior still holds, not as proof that the program is ready. The business statements above still need a human to judge them, and a suite that was written by the build team can test only what the build team expected.

Triaging defects before the go-live decision

Go-live decision procedure

1. Confirm that every business statement has a recorded result, not a verbal confirmation.
2. List open defects by class and confirm that no blocking class remains open.
3. Check that the data load reconciliation matches the source counts for each record type.
4. Confirm that the rollback path has been tested on the test instance, not only described.
5. Obtain sign-off from the process owner, the platform administrator and the sponsor, and record the date and version of what was signed.
6. Name the owner of the first post-go-live defect review and the date it will take place.

What to watch in the first weeks after go-live

• Proposals that stall in a single state, which often points to a routing or access gap.
• Records edited outside the defined process, which signals that the workflow is too slow for real use.
• Benefit figures that move when the source data has not changed.
• Users asking for the same workaround repeatedly, a sign that a training or design gap has been missed.

Can we test with a copy of production data?

Often yes, if the copy is masked for personal details and the handling rules are agreed in advance. Test with realistic values, including the messy ones, rather than a tidied sample, because the messy values are where the workflows often fail.

How many test users do we need?

One for every role that has a distinct permission in the design, plus one who holds no improvement role at all. The no-role user is the one that reveals whether the program is accidentally visible to everyone.

What if a defect is found after sign-off?

Classify it using the same table, then decide whether the sign-off still holds. A cosmetic defect often does not reopen the decision. A defect in routing or access does, and the sign-off record should show that the change was approved again.

Should the automated suite block a release?

It can, once the suite is stable and its failures are understood. Until then, a suite that blocks releases for reasons nobody can explain is likely to be bypassed, and a bypassed gate can be worse than no gate at all.

Next step before a go-live

If your acceptance evidence is mostly verbal, a short run of the business statements against a test instance can show the gaps quickly.