ServiceNow Hardware Asset Management Testing and Acceptance Checklist

This checklist sets out how to test and accept a Hardware Asset Management register before go-live. It covers inventory accuracy, the lifecycle and depreciation rules, the reports finance and operations rely on, the integrations that feed the register, and the evidence to keep for each sign-off.

Test Layers for Hardware Asset Management

Inventory Testing: verify that all hardware assets are in the system with correct details (serial number, model, location). Does the inventory match physical devices?

Lifecycle Testing: test asset states from purchase through retirement. New asset → in use → maintenance → retired. Can assets move through these states correctly?

Depreciation Testing: verify that asset values are calculated correctly. Is depreciation over the right timeframe? Are calculations accurate?

Reporting Testing: run asset reports and verify accuracy. Asset location, owner, depreciation value, age—all should be correct.

Entry and Exit Criteria

Entry: inventory data is imported (asset list with serial numbers, models, costs), depreciation policy is defined, and roles/workflows are configured.

Exit: inventory matches physical audit, lifecycle workflows work, depreciation calculations are correct, and reports are accurate.

Inventory Accuracy Checklist

Lifecycle and Depreciation Checklist

• New asset can transition to “in use” state.
• In-use asset can transition to “retired” state with appropriate documentation.
• Retired asset is removed from active inventory reports but retained for historical tracking.
• Depreciation is calculated correctly based on purchase price and depreciation policy.
• Asset value decreases properly each accounting period.
• Fully depreciated assets are handled correctly (kept at zero value or removed).
• Maintenance and repair tracking is enabled for in-use assets.

Reporting Checklist

• Asset inventory report is accurate (counts and values).
• Asset location report shows where hardware is physically located.
• Depreciation report shows book value by asset and in aggregate.
• Asset age report shows hardware that may need replacement soon.
• Retired/disposed asset report tracks what was removed and when.
• Asset owner accountability report shows who is responsible for which hardware.

Integration Checklist

If hardware assets are linked to CMDB: test that the link works and that asset data flows into CMDB correctly. A server in HAM should correspond to a server record in CMDB with the same serial number.

If procurement integrates with HAM: test that purchased hardware automatically creates HAM records or updates existing records with purchase information.

Evidence to Keep

Document inventory audit results (physical count vs. system count). Keep reconciliation notes: discrepancies found and how they were resolved. Keep test reports showing accuracy of depreciation calculations. Archive initial reports for comparison with future periods.

Sign-Off

Finance must approve depreciation calculations. Operations must confirm inventory accuracy. IT director must approve the asset lifecycle policy. Get all sign-offs before go-live.

Cross-Team Validation

Before sign-off, have multiple teams validate results independently. Finance checks depreciation. Operations checks inventory. IT director checks policies. Cross-team validation catches issues from different perspectives.

Asset Disposal and Retirement Tracking

When hardware reaches end-of-life, track its disposal. Was it recycled? Sold for scrap? Donated? Destroyed securely? This tracking is important for compliance (data destruction evidence) and environmental responsibility. Keep records for audit purposes.

Integration with Finance and Compliance

Coordinate testing with finance and compliance teams. Finance cares about accurate depreciation calculations for financial reporting. Compliance cares about asset tracking for audits and risk management. Their sign-off on testing is critical.

Make sure depreciation calculations match your finance team’s expectations and policies. Different organisations have different depreciation schedules. Validate that the system is configured for your specific finance policies before accepting it.

Ongoing Maintenance and Reporting

After go-live, assign ownership for HAM maintenance. Someone needs to manage hardware retirements, track additions, and keep cost data current. Without ongoing maintenance, the system degrades and becomes unreliable for decision-making.

Budget and Timeline Planning

Plan budget for the initial setup and ongoing maintenance. License costs if using asset management tools, staff time for inventory audits and data entry, and potentially hardware investment for better tracking (barcodes, RFID). Budget for training teams on the new system and processes.

Write the acceptance tests from the failures you cannot afford

Testing a hardware configuration usually starts with the happy path: create a device, assign it, retire it. That path is necessary and usually passes, so it tells the sponsor very little. The tests that decide whether the register can be trusted are the ones built from failures: a device that arrives with a serial number already in the register, a leaver whose laptop is still listed under their name a week later, a cost correction made after the period has closed. Build the acceptance list from the failures the business says it cannot absorb, and let the happy path be a short confirmation at the start.

Acceptance also needs a named decision-maker for each area. A test that passes technically can still be rejected by the receiving desk because the flow does not match how stock actually arrives. Agree who signs each area before testing begins, so that a rejection is not discovered at the final review. The decision rights behind those sign-offs should match the responsibility matrix for the lifecycle.

Test cases by transaction, with the negative case beside the positive one

The table lists the scenarios that most often separate a working register from a plausible one. Each row pairs the positive case with a negative case, because a register that accepts bad input without complaint has passed the first test and failed the second.

An ordered acceptance sequence

Run the tests in this order so that each area is only tested once its inputs are stable. Testing disposal before intake wastes effort, because the disposal tests depend on records that intake has not yet produced.

1. Confirm the test data is a copy of realistic records, with the duplicates and gaps that real data contains, rather than a clean set created for the test.
2. Run the intake scenarios first and have the receiving desk watch at least one full batch run.
3. Run custody and leaving scenarios next, with the service desk performing the steps rather than the project team.
4. Run the cost and period-close scenarios with finance present, using a period that has already closed in the ledger.
5. Run disposal last, including the refusal path, and record each evidence item against the test that produced it.
6. Collect sign-off from each named owner separately, and log any rejection as a defect with a severity agreed in advance.

Defects that are really design gaps

During acceptance, a common pattern is a defect that cannot be fixed without a process decision. A device can be issued from stock without a serial number because nobody defined the serial as mandatory for that class. A disposal can be closed without a certificate because the policy was never written down. Log these as design gaps rather than configuration defects, and route them to the owner who can decide. Fixing them in the configuration without the decision leaves the next team with a rule nobody can explain.

Measures for acceptance that do not depend on a single test run

Acceptance should show that the register stays right under normal use, not only that it passed once. Ask the operating team to shadow the register for a period after go-live, and compare what they did with what the register recorded. Keep a short list of recurring defects and confirm that each one has either closed or been accepted as a known limitation with an owner. Where the register feeds a report, confirm that the report’s totals reconcile to the register’s own records on the same day.

How many test records are enough for an acceptance run?

Enough to include each class of device, each site and each failure scenario in the table at least once. A large volume of identical records proves throughput but not correctness, and throughput can be tested separately if it matters.

Who should write the negative test cases?

The people who have seen the failures happen. Ask the receiving desk and the service desk to name the cases that have caused trouble before, and build the negative tests from those answers rather than from the specification alone.

Can acceptance be partial, with some areas accepted and others deferred?

Yes, but only where the deferred area has no dependency on the accepted one. Accepting intake while deferring disposal is reasonable if disposal records are not yet being created. Accepting cost while deferring intake is not, because the cost records depend on intake.

What should happen to the test evidence after go-live?

Keep it with the configuration change record, so the test history stays attached to the change it approved. The change validation evidence note covers the expected condition, evidence and conclusion a validation should state. Evidence kept only in a test tool is often lost when the tool is retired.