ServiceNow Knowledge Management Testing and Acceptance Checklist

Testing Layers for Knowledge Management

Testing a Knowledge Management rollout works in layers: unit checks that search finds each article, categories display and related links resolve; integration checks that incidents, requests and the service portal surface the right articles; functional checks of creation, approval, publication, expiry, versioning and archival; performance checks with realistic volumes; and user acceptance by the support staff who will live with the result. The sections below set entry and exit criteria, the detailed checklist, the evidence to keep, mobile, accessibility and content-quality tests, the regression traps, and how acceptance is signed off or withheld.

Functional testing verifies core features: article creation, approval workflows, publication, expiration, versioning, and archival. Performance testing verifies search responsiveness with realistic data volumes. User acceptance testing involves actual support staff and users confirming articles are accurate, findable, and useful.

Entry and Exit Criteria

Entry criteria define when testing can begin. You need: authoritative article templates, sample articles in each category, trained article authors, configured search settings, and upstream integrations (incident management, request fulfillment) configured and ready for testing. Testing should not begin until prerequisites are met.

Exit criteria define when testing is complete and implementation ready. All test cases must pass. No critical issues. Known issues must be documented and accepted. Performance benchmarks met: search responses within the target agreed for the project, and article load times acceptable. User acceptance sign-off documented. Support team trained on knowledge workflows and able to create and review articles independently.

Detailed Testing Checklist

Article creation and metadata: can you create articles, assign categories, set expiration dates, add related articles? Search and discoverability: can users find articles by keyword, category, or browsing? Do search results rank relevant articles first? Workflow and approval: do articles route for review, approval, and publication correctly? Expiration and archival: do expired articles disappear from search, and are they preserved in archive?

Integration with incident management: when an incident is created, are relevant articles offered to the support agent? Can agents link articles to resolve incidents? Portal integration: do service portal users see knowledge when they search for help? Mobile experience: is knowledge accessible on mobile devices? Performance under load: does search respond quickly with thousands of articles?

Evidence to Keep

Document test execution: what test cases were run, who executed them, what were the results? Keep records of defects found and how they were resolved. Maintain screenshots of successful searches and workflows. Document performance test results showing response times. Capture user acceptance sign-off showing support and user teams approved the implementation. Keep training records showing staff completed knowledge management training.

Mobile and Accessibility Testing

Knowledge Management must work on mobile devices. Users accessing knowledge from phones or tablets need responsive design, fast load times, and touchscreen-friendly interfaces. Test on real devices or emulators. Test article search on mobile—does it return relevant results in reasonable time? Test article reading on mobile—is text readable, are links large enough to click? Do embedded images load or cause performance issues on mobile networks?

Accessibility is often overlooked but critical. Articles must be readable by screen readers for visually impaired users. PDFs embedded in articles should be accessible. Colour should not be the only way to convey information. Test with accessibility tools and get feedback from users with accessibility needs.

Content Quality Testing

Automated testing catches structural issues. Manual testing catches content quality. Are articles accurate? Are code samples correct? Are instructions clear and followable? Do screenshots show the correct UI version? Content quality is subjective but critical—a technically sound but poorly written article is useless to users. Assign content reviewers who are expert in each domain to validate accuracy and clarity.

Common Regression Traps

A common regression happens when article content updates but search indexes do not refresh, so users see stale information. Test that article updates appear in search within expected timeframes. Another trap: articles are categorised but categories are invisible in the UI, so users cannot browse. Test that category hierarchies display correctly and help users navigate. A third trap: articles are created but never reviewed or published, so they are invisible to users. Test approval workflows ensure articles route correctly and are published on schedule.

Acceptance Sign-Off

Get written acceptance from: the incident management team (confirms articles help resolve incidents), the service desk (confirms support staff can create and review articles), user representatives (confirms articles are actually useful and find-able), and leadership (confirms the implementation meets business objectives). Do not proceed to go-live without documented acceptance from all stakeholders.

A test pass that answers whether readers can act on the article

Knowledge testing is often framed as a check that the platform works, which it does, and that the content is correct, which it may not be. The question an acceptance test should answer is narrower and more useful: when a real person with a real problem searches for help, do they find the right article, understand it, and finish the task without raising a ticket? That question needs test cases written in the language of the reader, run under the reader’s access rights, and scored against an outcome the reader would recognize. A test that only confirms an article is published tells you very little about whether it works.

Build the test set from real demand. Pull the most common search phrases and the most common resolution notes from the last period of work, and turn each into a case. A case without a source is a guess about what people will type, and guesses tend to test the vocabulary of the team that wrote the article rather than the vocabulary of the people who read it.

Relevance testing with the words people actually use

Relevance is where many acceptance problems hide, because a test script written by the build team will naturally search for the terms the build team uses. Ask a few people who were not involved in writing the content to run their own searches before anyone shows them the article titles. Record the phrases they try, whether they found the right article, and how many attempts it took. The gap between the phrase a reader used and the phrase in the title is a useful signal the test will produce.

1. Collect twenty or so real search phrases from the period before the test, including misspellings and abbreviations that the service desk has been using in its own notes.
2. Run each phrase as a reader with the intended audience role, and record the rank of the correct article, or note that it was absent.
3. For every miss, check whether the article’s title, summary and first paragraph contain the words a reader would expect. If they do not, rewrite those fields before changing any search configuration.
4. Re-run the failed phrases after the rewrite. Only then consider adjusting search settings, and record each setting change with the reason for it.
5. Repeat the pass with a different group of readers before sign-off, because the first group will have learned the vocabulary of the content by the time they finish.

Defects that only appear after publication

Some damaging knowledge defects do not show up until real readers arrive. A search index may lag behind an edit, so the old text is returned for a few hours after a correction. An article may be correct in the staff workspace and wrong in a portal that renders its tables differently. A link to a procedure may survive a migration while the procedure it points to has been split into two articles, leaving the reader at a summary that no longer contains the step they need. Acceptance criteria should therefore include a short post-publication check, run after the first real traffic, and an agreed route for logging what it finds.

When acceptance should be withheld

Withhold sign-off when the relevance pass still fails for the highest-demand topics, when restricted content can be reached by the wrong audience through any of the paths tested, or when the people who will maintain the content have not been trained to edit it. These are conditions where a go-live would put visible errors in front of readers and leave the owners unable to fix them. Consider a hypothetical team that signs off on the strength of a clean platform test but has not checked the search phrases from its own service desk. The first week of use is likely to reveal the gap, and the cost of that week is paid by the readers who were promised a working knowledge base.

Who should confirm that the articles are accurate before acceptance?

The subject matter expert for each service should confirm the technical content, and a reviewer should confirm clarity. Acceptance of the platform does not replace the accuracy sign-off, and the two should be recorded separately.

Do we need automated tests for knowledge content?

Some structural checks can be automated, such as required fields, broken internal links and missing owners. Content accuracy and findability still need human testing, so treat automated checks as a floor rather than as the acceptance test itself. Where the platform offers automated test suites, the governance notes on automated testing are a useful starting point for deciding what to automate.

How do we test that a retired article really disappears?

Search for it using the phrases recorded in the relevance pass, check related-article lists, and check any virtual agent response that once pointed to it. A retired article that still appears in one of those places is a defect even if the article record itself looks correct.

What if search results are correct but readers still open a ticket?

Then the article is being found and not trusted or not understood. Look at the feedback recorded against it, and check whether the first screen shows the answer or only the introduction. Testing the reading experience matters as much as testing the search.

Next step

The go-live hypercare checklist covers the period immediately after sign-off, and the requirements workshop questions cover agreeing decisions before the build starts.