ServiceNow Discovery Testing and Acceptance Checklist

This checklist sets out how to test a ServiceNow Discovery deployment before it moves to production and how to accept it. It covers functional, data quality, exclusion, regression and performance tests, the negative cases an acceptance plan must include, and the sign-off evidence the approver needs.

Test Layers for Discovery

Discovery in ServiceNow automatically identifies IT assets: servers, workstations, network devices, applications and their relationships. Testing Discovery requires multiple layers. Functional testing validates that the discovery process runs without errors and finds assets in your environment. Data quality testing validates that discovered data is accurate (the server name, IP address, operating system match reality). Performance testing validates that discovery does not consume excessive resources during execution. Regression testing validates that changes to discovery patterns do not break existing functionality.

Plan your testing in phases. Start with a small test environment: one subnet, one discovery probe, a known set of assets. Validate that discovery finds the expected assets. Then expand: additional subnets, additional device types. Finally, run against your full production environment in a sandbox (a copy of production data) to catch any surprises before discovery runs in production.

Entry and Exit Criteria

Before you begin discovery testing, establish entry criteria: what state must the environment be in before testing starts? The discovery probes must be installed and configured, test credentials must be set up for each device type, test assets must be deployed in the test environment, and the discovery patterns must be configured (if customised).

Exit criteria for discovery testing: all functional tests pass, data validation shows accuracy above a defined threshold (for example, the vast majority of asset names match the actual device), performance benchmarks are met (discovery completes within an expected window), no critical defects remain, and operational teams have signed off that the discovered data meets their needs.

Functional Test Checklist

Test these scenarios: does the discovery probe connect to the discovery server and receive jobs? Does discovery connect to your network and identify devices by IP address? Does discovery authenticate to devices using stored credentials? Does discovery correctly identify device type (server, workstation, network device, storage)? Does discovery capture key attributes (hostname, IP address, operating system, installed applications)? Does discovery identify relationships (which application runs on which server)? Does discovery correctly exclude devices that should not be discovered (printers, personal devices)? Does discovery fail gracefully if credentials are wrong or if a device is unreachable?

For each test, document the expected outcome and verify the actual outcome. If actual differs from expected, capture the gap and route to development for investigation.

Data Quality Checks

Discovered data is only useful if it is accurate. Spot-check discovered records: select ten servers at random and verify that the discovered hostname, IP address, and operating system match reality. Sample discovered applications: pick five applications and verify that they are installed on the servers where discovery says they are. Sample network devices and verify their configuration details.

Also check for completeness: are there assets in your environment that discovery did not find? Walk a few network segments manually and see if discovered devices include everything you expect. Document any gaps: printers not found, virtual machines not found, cloud services not found. Gaps often indicate that discovery patterns need configuration for those asset types.

Exclusion Rules Testing

Discovery patterns include exclusion rules: discover everything except printers, discover everything except out-of-support operating systems. Test that exclusion rules work correctly. Create test devices that match the exclusion criteria and verify they are excluded. Create test devices that do not match the criteria and verify they are discovered. For example, if you exclude devices with IP ranges 10.50.0.0/16, verify that a device with IP 10.50.1.1 is excluded and a device with IP 10.60.1.1 is discovered.

Regression Test Scenarios

After you implement custom discovery patterns (for your proprietary application servers, for example), run regression tests to confirm standard discovery still works. Ensure that adding a custom pattern for database server discovery does not break the standard Windows server discovery pattern. Run the standard test suite after each customisation.

Performance and Resource Validation

Discovery can consume resources: network bandwidth (sending discovery probes to many devices), CPU (processing discovery results), and database I/O (writing discovered data to the CMDB). Before production, estimate resource consumption. If you have 10,000 servers to discover, how long will discovery take? How much network bandwidth will it consume? Will it interfere with production monitoring?

Run discovery in a sandbox against a representative subset of your production environment (perhaps a few hundred assets). Monitor resource consumption. If discovery takes longer than an acceptable window (for example, you want discovery to complete within a one-hour maintenance window), you may need to adjust discovery patterns, run discovery in batches, or schedule discovery during low-demand hours.

Acceptance Signoff

Before moving discovery to production, obtain signoff from: the CMDB owner (confirms data accuracy), the IT infrastructure team (confirms discovery does not cause problems), and the business owner (confirms the discovered asset inventory meets their needs). Document any known gaps or exclusions, so there are no surprises after deployment.

Test what should fail, not only what should work

Many discovery test plans prove that a scan finds a server it is pointed at. That is the easy half. The harder half is proving that discovery refuses to do the things it must never do: reach a segment outside its approved scope, use an account it was not given, create records for devices that are powered off and were never in the inventory, or promote a batch that a reviewer rejected. A test plan with no negative cases can pass on the day of acceptance and then surprise the team at the first audit. Build the negative tests first, because they define the boundary the rest of the plan has to respect.

The negative cases do not need to be exotic. A single host in an excluded subnet, a retired host still listed in the address plan, and a device that answers on the wrong port are enough to show whether the scope and the exclusion rules are doing their job. Each case should have a stated expected result written before the test runs, so that the outcome cannot be explained away afterwards.

Negative cases that belong in every acceptance plan

An ordered sequence for running acceptance

1. Freeze the scope document and the exclusion list, and give each a version number that the test evidence will cite.
2. Run the negative cases first, while the environment is in its most constrained state, so that any leak is obvious.
3. Run the positive cases against a known set of targets whose true configuration is written down, so that accuracy can be measured rather than judged.
4. Compare discovered records with the reference list and log each difference as a defect, an accepted variance or a data-source issue.
5. Run a repeat scan without changes and confirm the second run produces no unexplained differences. Instability between identical runs is a defect even when the first run looked right.
6. Assemble the evidence pack and have the approver sign it, separately from the people who ran the tests.

Triaging defects without losing the thread

Discovery defects tend to split into three groups. Configuration defects are in the scope, the credentials or the schedule and can be fixed without code. Data-source defects come from the systems being discovered, such as a host that reports a wrong model. Design defects mean the approach cannot meet the requirement. Label each defect with its group when it is raised, because the fix and the owner differ. A team that treats every defect as a configuration problem can keep retrying a design defect until the schedule slips.

Accepting with conditions

Full acceptance is not always realistic on the first cycle. A reasonable outcome is acceptance with named conditions: a defined set of accepted variances, a date for closing each open defect, and a rule that the variance list is reviewed at the next governance meeting. Conditions should never cover a negative case. If discovery reached an excluded segment, the release is not accepted until that path is closed and retested.

Questions about discovery acceptance testing

How should the team test accuracy without a complete reference inventory?

Use a sample. Choose a set of targets that span the device classes in scope, record their true configuration from a source outside discovery, and compare. Be explicit that the sample measures accuracy in the classes it covers and does not stand for the whole estate.

Who should write the expected results?

Someone who did not build the configuration. The author of the scope document is a good choice, because their expectations are the ones the acceptance must test against.

Can acceptance be run in production?

Positive cases can run against production targets with read-only collection. Negative cases that involve an excluded range or a rejected batch should run in a controlled environment or be designed so that they cannot write data, since a failed exclusion test in production can create records that then need removing.

Take the checklist to a specialist review

If you want an independent view of your acceptance plan before the first full run, review the negative cases and the evidence pack with someone who did not write them. The Discovery implementation roadmap shows where acceptance sits in the wider sequence, and the KPIs and metrics page is the place to look at which measures to track after acceptance. The scope decisions for a first release are worth settling before the scope document is frozen.