ServiceNow MID Server Testing and Acceptance Checklist

A MID Server acceptance test is the check that a server can reach ServiceNow, connect to every target it will serve and carry its share of work under load before it is trusted in production. The page sets out the test layers, the checklists and a regression set for accepting later changes to a running server.

Test Layers for MID Server

Unit Testing: test individual MID Server components in isolation. Can the MID Server start and maintain a heartbeat to ServiceNow? Can it execute a simple script? Does it log events correctly? Each component should work alone.

Integration Testing: test MID Server with the systems it will integrate with. Can it connect to the database? Can it execute PowerShell on a Windows server? Can it authenticate to the monitoring tool? Test integration with each external system before accepting MID Server for production.

Load Testing: test with realistic traffic. If the MID Server will run 100 concurrent jobs, simulate that. Does performance degrade? Does memory or CPU spike? At what point does the MID Server become a bottleneck?

Failover Testing: if you have multiple MID Servers, test failover. Stop one server and verify the other takes over. Do jobs continue or are they lost? Test failover in a controlled environment, not production.

Entry and Exit Criteria

Entry Criteria: MID Server is installed, network connectivity from MID Server to ServiceNow has been validated, and all integration credentials are ready. You cannot start testing without these.

Exit Criteria: connectivity tests pass, integrations work end-to-end, performance under load is acceptable, and security reviews are complete. Every layer must pass.

Connectivity and Network Testing Checklist

Integration Testing Checklist

Performance and Load Testing

Run the MID Server with typical load for one week. Monitor CPU, memory, disk I/O, and network usage. Are resources stable, or trending upward? If trending upward, investigate why before accepting for production.

Run a peak load test: simulate the maximum number of concurrent jobs the MID Server is expected to handle. If the maximum is 100 jobs, run 100 jobs simultaneously. Measure response time and resource usage. If response time becomes unacceptable or resources max out, document the limit and note for capacity planning.

Regression and Rollback Testing

Before accepting MID Server for production, test rollback scenarios. If you need to revert to an earlier version of MID Server, can you restore it without losing jobs or connectivity? Have a rollback plan documented and test it in a non-production environment. Regression testing also includes re-running all previous test cases after configuration changes to ensure nothing breaks.

Security Review Checklist

• MID Server credentials are stored in encrypted credential tables, not plaintext files.
• MID Server user account has minimal permissions (not domain admin or local admin unless absolutely required).
• MID Server runs with service account isolation: its credentials are not used for anything else.
• Firewall rules are restrictive: MID Server can only reach the systems it needs to reach, not all systems.
• Audit logging is enabled: MID Server actions are logged for compliance.
• Anti-virus and endpoint detection are configured for the MID Server but not interfering with its operation.

Evidence to Keep

Document all test results: pass/fail status, dates, who ran the test. Keep logs from MID Server during testing (connectivity, job execution, errors). If issues arise post-go-live, these logs help troubleshoot.

Keep the list of target systems tested and the results. If new targets are added later, you have a baseline for comparison.

Sign-Off

Get approval from operations (who will manage the MID Server), security (who reviewed credentials and access), and infrastructure (who validated network connectivity). All stakeholders should confirm the MID Server is production-ready before it goes live.

Acceptance testing for a change to a MID Server that already works

Much acceptance guidance assumes a new installation. In practice a team spends more time accepting changes to a running estate: a patched host, a new cluster member, a moved virtual machine, or a rotated certificate. Each of these can break something that worked yesterday, and the failure is often silent. A discovery schedule keeps running but returns fewer records. An integration reports success while writing to a stale endpoint. The acceptance test for a change has to prove that the existing behavior survived, not only that the new component starts.

The useful unit of testing is the job class, not the server. Discovery, event collection, orchestration and credential checks each exercise a different part of the host and the network. A change can pass the connectivity check and still fail every orchestration job, so keep a short list of representative jobs from each class and run them after every change.

Regression set for a running MID Server

Build the regression set once, keep it in the change record, and reuse it. The table shows the shape that works well. The baseline column is the important one, because a result is only meaningful against a recorded starting point.

Ordered procedure for accepting a change

1. Record the current baseline for each job class in the regression set before the change starts, not after.
2. Apply the change to one cluster member, or to a copy of the host in a non-production estate where that is possible.
3. Run the regression set and compare each result with the baseline, noting any difference even when the job reports success.
4. Leave the change in place for a full cycle of scheduled work, because some jobs run weekly or monthly and will not appear in a single test window.
5. Check the logs of the host and the instance for new warnings that were not present in the baseline period.
6. Roll the change to the remaining members one at a time, repeating the comparison after each one.
7. Sign the change off with the owner of each job class, not only with the person who applied it.

Why a single successful run is not enough

A scheduled job that runs weekly will not reveal a problem on the first run after a change if the problem only appears when the job reads a large dataset. Give the change a full cycle before accepting it.

Testing a rollback as part of acceptance

A change is not fully accepted until the team has shown that it can be reversed. Test the rollback on the non-production copy, and write down the time it takes and the steps it needs, so the on-call person does not discover them during an incident.

Handling a change that passes every test but feels wrong

Sometimes the numbers look right and the discovered records are subtly different. Pull a sample of records and compare their attributes by hand. If the differences are real, reject the change; a reviewer’s judgment is valid evidence when the baseline is documented.

Who owns the regression set

The MID Server administrator maintains it, and each service owner approves the job classes that concern their integrations. A set nobody owns tends to decay as integrations change.

Where acceptance fits in the wider rollout

Acceptance testing for an existing estate is a repeatable part of the operating model, not a one-off project gate. The implementation roadmap for MID Servers sets out the rollout gates, and the best practices guide covers the configuration habits that make a regression set easier to keep. Where the change touches automated release gates in the wider platform, the automated testing and release assurance work covers automated testing for release assurance.

If a change keeps failing acceptance and nobody can say why, bring the test results and baseline to a conversation with the people who own the affected job classes before attempting another fix.

Questions about accepting MID Server changes

Do we need a separate test instance for every change?

Not for every change. A configuration tweak can be tested on one live member with a rollback ready. A change to the host operating system or the runtime should be tested on a copy first.

What should happen when the baseline itself was wrong?

Record the correction as a change to the baseline, with the reason and the approver. An undocumented baseline change makes every later result harder to trust.

Can acceptance be partly automated?

The comparison of counts, timings and heartbeats is well suited to automation. The review of payload structure and record attributes usually still needs a person.