ServiceNow Upgrades and Release Readiness Testing and Acceptance Checklist

This checklist helps a team decide what to test before a ServiceNow upgrade reaches production. Regression is the main risk, because the platform code changes under configuration that already worked. It covers test scope, four test layers, preparation, defect triage, the go or no-go decision and the evidence to keep.

Purpose and Scope of Upgrade Testing

Test Scope: What to Test

Out of Scope (handled by ServiceNow): Platform-level features (workflow engine, UI framework, API layer) that have no customer customization. ServiceNow tests these thoroughly.

In Scope (you must test): Custom code (scripts, plugins, business rules), custom tables and fields, integrations with external systems, custom reports and dashboards, customized workflows, third-party apps and extensions.

Scope testing by risk: high-risk (custom scripts, integrations, core workflows) get thorough testing. Low-risk (custom field visibility, report formatting) get smoke testing.

Test Layers

Smoke Testing: Quick validation that system is working. Create a record, update it, delete it. Access a few key workflows and reports. Duration depends on how many workflows you check. Done in test environment immediately after upgrade.

Regression Testing: Run previously passing test cases to ensure they still pass. Document any failures. Duration depends on system complexity and the number of test cases.

Integration Testing: Test integrations with external systems. Verify data still flows correctly, API calls still work, error handling works. Duration depends on the number of integrations.

User Acceptance Testing: End-users test their workflows and processes, verify nothing is broken. Duration depends on workflow count.

Pre-Upgrade Preparation

Before upgrade: backup all custom code and configurations. Document existing behavior (how does this workflow work?). Create test data set representative of production volume and mix. Identify high-risk areas that need extra testing. Schedule upgrade in low-volume period if possible. Notify users; set expectations that system may be slower or temporarily unavailable.

Upgrade Testing Checklist

Defect Triage and Decision

As testing identifies issues, triage by severity: critical (system down, data loss, security breach) must be resolved before production. High (core workflow broken, integration down) should be resolved before production. Medium (feature degraded, UI issue) can be accepted if business agrees to live with issue temporarily. Low (cosmetic, edge case) can wait for next patch.

For each defect: investigate root cause (is this a platform issue or custom code issue?), document workaround if not immediately fixable, estimate effort to fix. Plan resolution: some issues can be fixed before go-live, others must be fixed post-go-live with priority.

Regression Traps to Avoid

Trap: Script updates. ServiceNow platform changes sometimes require script updates. If your custom scripts were written for previous release, they may break in new release. Check ServiceNow release notes for breaking changes. Test all custom scripts thoroughly.

Trap: Database schema changes. Rare, but new releases sometimes alter tables. If your custom code depends on specific schema, it may break. Test data operations (create, query, aggregate) thoroughly.

Trap: Third-party plugin incompatibility. Apps and plugins may not be compatible with new release. Test all installed apps in test environment before production upgrade.

Trap: Timezone and data type issues. Release updates can affect how dates are handled or how data types are coerced. Test date-dependent workflows and aggregations.

Evidence to Preserve

Keep test results: test case, input, expected output, actual output, pass/fail status. Keep logs from testing phase: any errors or warnings in platform logs. Keep screenshots of key workflows and reports. This evidence supports postmortem if issues emerge in production and helps with future upgrades (identify weak areas that always break).

Post-Upgrade Support Plan

After production upgrade, have support team on standby for the early period after go-live. Issues often emerge after users start working with system. Keep rollback plan ready (revert to previous version if critical issue found), though full rollback is risky and should be last resort. Have escalation path: if issue is found post-upgrade, who do you call?

Capture the baseline before the upgrade starts

An upgrade test only means something when you can compare the result with what the system did before. That sounds obvious, and yet many teams run their checks against the upgraded copy and record whether the outcome looks right. A check that asks “does the approval route work” will pass on a broken route if the approver is the same person who tested it. The comparison that catches regressions is the one that runs the same input against the old release and the new one and asks whether the output changed.

To make that comparison possible, capture a baseline on the current release before the first clone is upgraded. Export a fixed set of records, record the outputs of key reports and scheduled jobs, and save the response times and error counts from the integration logs. Use the same data set on both sides. Without that discipline the team is left comparing a memory of how something used to behave with a fresh observation.

Choosing where testing effort goes

A test plan that gives every item the same weight will spend much of its time on the low-risk items. Weight the effort by how much damage a silent failure would do. A quiet fault in a scheduled job that closes records at night is worse than a visible fault in a dashboard tile, because nobody looks at the job until the damage is done.

A procedure for turning results into a go or no-go

Results are only useful when they are read in the same way each time. The procedure below gives the test lead a fixed route from raw output to a recommendation.

1. Freeze the test data set and the list of cases before any upgraded clone is tested, so cases cannot be quietly added after a failure.
2. Run each case on the baseline release and the target release, and store both outputs side by side.
3. Diff the outputs automatically where the output is structured, and review the differences by hand where it is not.
4. Classify each difference as expected by the release notes, caused by custom code, or unexplained.
5. Mark any case that could not be run as not run, with the reason and the name of the person who accepts that risk.
6. Issue the recommendation only when every unexplained difference has an owner and a decision.

Patterns that make a passing test meaningless

• An assertion that checks a record exists but not that its values are right, so a field overwritten with the default still passes.
• A test environment whose installed plugins differ from production, so a conflict that would appear in production never shows up.
• Scheduled jobs that never fire during testing because the test clock was not advanced, and are then reported as working.
• Cases skipped to meet a date and recorded as passed in the summary sheet.
• Results rerun until they pass, with the failed runs deleted from the log.

Each of these is easy to avoid when the baseline and the frozen case list exist. Each is hard to spot afterwards when they do not.

Questions about upgrade test evidence

How many cases are enough?

Enough to cover the high-risk areas in the list above with real comparisons, not a count to report. A short set of well-chosen cases, compared against a baseline, tells you more than a long set that only confirms pages load.

What do we do with a failure we cannot reproduce?

Record it, capture the logs and the exact data used, and rerun it on the same environment. If it still cannot be reproduced, classify it as unexplained and keep it open until someone owns the question. Dropping it from the log is the one option that is never acceptable.

Should the business run its own tests in parallel?

Yes, for the processes it owns. Business validation catches problems that technical comparisons miss, such as a correct value shown in an unexpected place. Keep those results in the same evidence store as the technical results.

How long should we keep the evidence?

Keep it until the upgrade has been reviewed and the next release cycle has used its lessons. Those records are the best source for knowing which areas tend to break.

Setting the bar a pass has to clear is covered in the note on testing strategy and release evidence. Test roles and the access they need are covered on the access design page.

A phase-by-phase ServiceNow upgrade checklist with owners and exit tests

An upgrade checklist works best as five phases, each with one owner and one condition that must be true before the next phase starts: baseline, rehearsal, business validation, cutover and stabilisation. A flat list of test items tells you what to check; the phases tell you who signs off and when to stop.

Rehearse on a fresh clone

The rehearsal is where most upgrade surprises should appear, so give it the time and the people it needs rather than treating it as a formality.

Run the rehearsal on a clone taken shortly before the test, not on a test instance that has drifted for months. A drifted instance hides problems that production will show, and it can show problems that production does not have. Take the clone, apply the upgrade, then run the same baseline comparison you saved in phase one.

Freeze configuration movement and agree the rollback point

Stop moving update sets between instances once the rehearsal starts, so the test result describes the code that will go live. Agree before cutover who may call a rollback, by what time, and on which evidence. Teams that decide this during the night usually decide late.

For the surrounding material, see the upgrades and release readiness guides, the notes on update sets and release management, and the platform performance and upgrade readiness service.