Why You Test

✅
Validate
  • Confirms applications being developed meet requirements, needs, and expectations
📋
Verify
  • Confirms applications conform to the specifications defined in the user development stories
🛡️
Protect
  • Ensures new functionality does not introduce unwanted regressions to existing functionality

Core Testing Types

🧩
Story / Unit Testing
  • Smallest testable software component (object, component, module)
  • Focuses on programming errors, tested in isolation
🔗
System Testing
  • Assesses the system holistically, including integration testing
  • Verifies overall specifications and intended purpose
🙋
User Acceptance Testing
  • Final validation stage, completed by end-users
  • Confirms the platform meets business outcomes

Risk-Based Testing Funnel

1
Take a risk-based approach — start with the most business-critical applications
2
Within that application, identify the business-critical process flows (e.g. the top 10–20 user process flows for Incident Management)
3
Within those flows, identify the unique configurations specific to the customer's instance
4
Focus testing on those unique configurations — not on out-of-the-box functionality ServiceNow has already tested
5
Use the default Quick Start Tests as guidance and a jumpstart for building your own tests
💡 Leading practice: Do not try to test everything, and do not re-test out-of-the-box configuration that ServiceNow has already tested. A risk-based, configuration-focused scope keeps testing manageable and repeatable.

Method Comparison

🧑‍💻 Manual Testing Human-Led
Executed by a human tester using the Test Management application.
  • Exploratory testing — tester skill, creativity & intuition where documentation is light or time is short
  • Usability testing — human observation of how user-friendly the product is
  • Ad hoc testing — unplanned, driven purely by tester insight
Trade-offs: less reliable (human error), time- and resource-intensive, but allows genuine human observation.
🤖 Automated Testing Tool-Led
Executed via the Automated Test Framework (ATF), used for both implementations and release upgrades.
  • Regression testing — standardized, repeatable test runs
  • Repeated execution — tasks that need to run over and over
Trade-offs: more reliable and significantly faster, practical for long-running repeated cases, but requires upfront tooling investment and no human observation.
🤖 Now Assist for Creator can generate ATF tests from natural-language prompts — interpreting instructions and building complete test cases without manual construction.

Development → Test → Production

Development
Story / Unit Test
ATF Implementation
ATF Execution
Developers unit test their own configuration, then request peer review from another developer or solution architect before the story moves on.
Test
System / Integration Testing
User Acceptance Testing (UAT)
ATF Execution
QA validates overall system interaction and integrations; business stakeholders validate against requirements before the story closes.
Production
Smoke Test *
A quick, non-exhaustive check that the most important functions work immediately after deployment — before full QA takes over.
🎨 Colour key from the source module: types highlighted in grey are manual, types highlighted in green are automated. *A smoke test is also known as a "build verification test."

Special Test Types

🔁
Upgrade Testing
A special, program-wide form of regression testing that verifies existing functionality after changes introduced by ServiceNow. A mature testing strategy with strong automated coverage makes upgrades far easier.
Scope Depends On →
Family upgrade (e.g. Yokohama → Zurich) Patch-level regression Customer risk profile
🧭
Non-Functional Testing
Tests how a system operates rather than its specific behaviours. A high-maturity topic that often requires specialist know-how and outside tooling.
Covers →
Usability Performance Localization & Internationalization Documentation
📈
Load Testing
Simulates expected production load with automated tooling to validate performance ahead of go-live or an upgrade. Designed to mirror real-world usage — it is not a stress test.
Requires →
Dedicated isolated environment Production-sized instance Planning & coordination with ServiceNow
⚠️
Load testing caution: load tests must not be run against production or sub-production instances without proper prior planning — ServiceNow's Cloud Infrastructure and Operations teams guard against this during peak hours because of the potential impact on underlying system and server performance.

Penetration & Security Testing Policy

1
Approval — customers are permitted one penetration test per year; scheduling must be pre-approved and agreed with ServiceNow, and a minimum HealthScan score may be required
2
Prerequisites — the instance must be upgraded to the latest release/patch with ServiceNow's hardening guide applied, or findings risk being false positives
3
Benefits — confirmed findings strengthen the collective ServiceNow security posture and are remediated per ServiceNow's vulnerability management criteria
4
Review & response — each finding is submitted via the Security Findings tracker within 30 days of the testing window closing; confirmed issues open a linked PRB record

Three Data Lifecycle Tools

🧹
Table Cleaner
  • Hourly scheduled job that deletes records older than a configured age (sys_auto_flush rules)
  • Bulk mode (chunk or nibble) or Iterative mode
  • Best when an archive is not required
🗄️
Table Rotation / Extension
  • Splits high-volume logical tables into physical "shard" tables
  • Rotation reuses shards — data is transient
  • Extension keeps growing shards indefinitely (e.g. sys_email, sys_audit)
📦
Archiving
  • Moves older records to an archive table (e.g. task → ar_task) via the free com.glide.auxdb plugin
  • Free in cost, expensive in system resources — throttled by design

Archiving Building Blocks

1
Archive Rules — configured to give fine-grained control over which records are migrated to the archive table
2
Destroy Rules — configured to control permanent removal of old records from the archive table
3
Scheduled Job — runs periodically to physically migrate records from the live table to the archive table

Data Cleanup Toolkit Compared

Tool Reduces Disk Space Improves "Working" Dataset DB Overhead per Record
Table CleanerYesNo#3
Table RotationYesYes#1 – Best
Table ExtensionNoYes#2
ArchivingPotentiallyYes#4 – Worst
⚠️
Use archiving with caution: it adds real database load and can cause replication lag. Reserve it for core business data that needs audit access, and configure it early in the instance's life — it is not a good strategy for addressing performance issues once they are already apparent.

Query Strategies for Large Data Sets

1
Time-boxing — apply a range/restriction on a sequential field to narrow results; when the field is indexed, these queries stay efficient even at scale, and are ideal for delta views
2
Task table optimization — over 90% of operations touch the task table; querying active=true lets the platform skip the ~90% of inactive tasks in a typical instance
3
Disable unnecessary auditing — at table or field level, especially for high-volume or frequently re-loaded/imported data

Three Ways to Queue Work

Scheduled Jobs
The Background Scheduler claims up to 20 jobs at a time across 8 worker threads per node (7 routine + 1 burst worker for high-priority jobs waiting >60s).
Off-peak scheduling Priority + burst support 5–10s claim lag No record for jobs <1s
Event Queue Processing
Asynchronous events (notifications, integrations, scripted actions) are written to the sysevent table and processed without blocking the user's transaction.
Loose coupling Historical record retained Single thread per node Vulnerable to slow operations
Async Business Rules
Server-side scripts that run after the database operation completes, outside the user's immediate transaction, via the sys_trigger table.
Faster perceived response Priority-based queue position Can hide inefficiency "current" set at execution time
⏱️ Before shipping async logic: test it on a sub-production environment, confirm expected response time, and validate the code cannot get stuck — a hung async job hangs a worker thread.

Memory Management Pitfalls

1
Avoid creating unnecessarily large arrays or strings in script
2
Don't hold GlideRecord/GlideElement objects in memory longer than needed — dot-walking straight onto an array wastes memory versus checking for uniqueness as the array is built
3
Watch for infinite or very deep loops; wrapping business rule logic in functions lets variables fall out of scope and be garbage-collected once the rule completes

Recurring Performance Activities

🗓️
Daily
Review the System Diagnostics homepage — tracks high-level statistics for each node (JVM) in the instance. Review yesterday's slow transactions — requires the Client Transaction Timings Plugin to capture full data.
Diagnostics · Slow Transactions
📆
Weekly
Review scheduled job activity (reports, discovery sensors, data loads). Check for excessive logging via System Logs → Utilities → Node Log File Download. Trend the top 20 transactions by volume or business-criticality.
Jobs · Logs · Transactions
📊
Monthly
Monitor table growth rates and correlate against response-time trends. Review the Slow Queries log (System Diagnostics → Stats). Review slow scripts and slow transactions (syslog_transaction aggregation).
Growth · Queries · Scripts

Continual Improvement at Scale

🔁 Continual improvement: implementation is done by people, and people make mistakes — treat issues as an opportunity to improve. Assess across three levers:
👥
People
  • Are developers trained properly?
  • Is there a feedback loop established?
📐
Process
  • Are clear guidelines for design and implementation established?
  • Are they regularly updated to reflect issues identified in operations?
💻
Technology
  • Does the instance landscape support proper testing of all functionality before go-live?
  • Are there constraints — e.g. missing integrations on test instances?
  • Is production-size data available on test instances?
Takeaway 01
Understand Testing Methods
Familiarize yourself with manual, automated, and special testing approaches to ensure comprehensive coverage.
Takeaway 02
Prioritize Regression Testing
Ensure stability and functionality after updates or code changes, and lean on ATF to create reusable tests and streamline validation.
Takeaway 03
Start Testing Early
A plan and early testing help identify and resolve issues before they escalate into production problems.
Takeaway 04
Establish Monitoring Routines
Regular checks and daily habits are what sustain instance hygiene — not one-off clean-ups.
Takeaway 05
Use Data Management Tools
The Data Management Console, Table Cleaner, table rotation/extension, and archiving each solve a different data-growth problem — pick the one that fits.
Takeaway 06
Plan Strategically
Design architectures that support growth and efficiency, and implement proactive measures before performance issues become critical.