# Application Testing and Troubleshooting

> Chapter 15 of the Courseiva SERVICENOW-CAD curriculum — https://courseiva.com/learn/servicenow-cad/application-testing-and-troubleshooting

**Official objective:** 9.1 — Test and debug applications using system logs and debugging tools

## Introduction

If you cannot find out why your app is broken, you will fail the SNOW-CAD exam because you cannot fix what you cannot see. Application testing and troubleshooting is how you prove your app works correctly and how you hunt down bugs when it does not. This chapter teaches you the systematic approach to debugging in ServiceNow using built-in logs and tools, so you can confidently fix issues and earn your certification.

## The Detective Inspector Analogy

A Detective Inspector is called to a scene where a security alarm failed to trigger. The business owner is furious – a package went missing overnight. The Inspector does not start by accusing anyone. Their first job is to check the logbook. This is a physical book where every guard writes down what they saw during their rounds, at what time, and any unusual event.

The Inspector flips through the logbook, looking for gaps. If a guard checked Building A at 10pm but did not write an entry for Building B until 1am, the Inspector knows there is a three-hour window where something could have happened. They then look for patterns. If the alarm panel log shows a 'door ajar' message at 11pm, but the guard log says 'all clear' at that same time, the Inspector knows someone has lied or made a mistake. They now have a specific point to investigate – they can interview the guard about that ten-minute period.

This is exactly what application testing and troubleshooting is in ServiceNow. You are the detective. The logs are your logbooks. The debugging tools are your magnifying glass and fingerprint kit. When a button in your app does not work, you do not guess why. You look at the system logs to find the exact moment the button was clicked, what the system tried to do, and where it failed. You collect evidence methodically, not randomly. This prevents you from wasting time on theories and focuses you on the true root cause – just like a good inspector who reads the logbook before knocking on any doors.

## Core explanation

Application testing and troubleshooting in ServiceNow is the process of making sure your custom application behaves as expected, and finding and fixing problems when it does not. It is a skill you will use every day as a developer.

Before we dive in, let us define some key terms. A 'bug' is an error in your code that causes unexpected behaviour. 'Debugging' is the act of finding and removing those bugs. 'Logs' are text records of events that happen in a system – think of them as a diary that the server writes automatically. 'Troubleshooting' is the broader process of identifying, diagnosing, and resolving a problem.

Why does testing matter? Because you cannot deploy an application to real users that is full of mistakes. A single bug could prevent a critical record from being saved, show wrong data to a manager, or even break another application that depends on yours. ServiceNow runs on the Now Platform, which is a single platform shared by many apps. A bug in your app can affect others, so ServiceNow provides robust tools to help you test and debug.

There are several types of testing you need to know for SNOW-CAD:

- Unit testing: testing individual components of your app in isolation. For example, checking if a single script runs correctly. This catches small errors before they become big problems.
- Integration testing: testing how your app works with other parts of the system, like sending an email notification when a record is updated.
- Regression testing: re-running tests after you make changes to ensure you have not broken anything that used to work.
- User acceptance testing (UAT): having real users try your app to see if it meets their needs.

The two most powerful debugging tools in ServiceNow are the 'System Logs' module and the 'Debug' tool. System Logs are found under 'System Logs > System Log > All'. They record every transaction that happens – script executions, errors, warnings, and informational messages. You can filter by date, type (error, warning, info), and source (which part of the system generated the log).

The 'Debug' tool is even more powerful for developers. When you activate 'Debug' on a script, it runs step by step, and you can see the value of every variable at each line. This is like watching a movie frame by frame instead of at normal speed. You can see exactly where your calculation goes wrong or why a condition is not met.

Another essential tool is the 'Background Scripts' feature, found under 'System Definition > Scripts > Background'. This lets you run any Servicenow script in a safe sandbox without affecting live data. You can test a line of code, check if a GlideRecord query returns the correct records, or simulate a user action. It is a safe space to experiment.

ServiceNow also uses a concept called 'Business Rules'. These are scripts that run automatically when a record is created, updated, deleted, or displayed. When troubleshooting, you must check if a Business Rule is interfering with your app. For example, if you update a record but the change is not saved, a Business Rule might be reverting the change. You can find Business Rules under 'System Definition > Business Rules'.

Finally, there is the 'Application File' inventory. Every customisation you make – scripts, tables, forms, reports – becomes part of your 'Application'. You can compare versions of your application files to see what changed between two updates. This is crucial when a feature stops working after a new release; you can compare the current version with the previous one and spot the change that broke it.

To put it all together: testing is proactive; you do it before your app goes live to catch bugs. Troubleshooting is reactive; you do it after a problem is reported. Both rely on the same tools: logs to see what happened, debug to see step-by-step execution, background scripts to test in isolation, and business rules to understand automated behaviour.

## Real-world context

An IT professional working for a large retail company has built a custom ServiceNow app called 'Employee Onboarding'. The app automates the creation of accounts, email distribution lists, and desk assignments for new hires. The onboarding process involves three departments: HR, IT, and Facilities. The app uses Business Rules, Flow Designer flows, and an ACL to restrict data access.

One Monday morning, the HR team reports that new employees are not receiving their welcome email after the IT step completes. The email used to work last week. The IT professional now steps through a real troubleshooting process.

First, they check the system logs. They navigate to 'System Logs > System Log > All' and filter by the time frame when the latest hire was processed (e.g., 9am to 10am today). They look for errors with the source 'Flow' or 'Email Notification'. They see a line that says 'Script error: Cannot read property 'email' of null' at 9:32am. This tells them that a script tried to read an email address from a record that does not exist (null).

Now they know the problem is related to a null field. They open the Flow that sends the welcome email (found under 'Process Automation > Flow Designer'). They examine the step that prepares the email. The Flow uses a GlideRecord query to look up the new employee's user record by sys_id. The query returns null, meaning the record was not found. The likely cause is a timing issue – the IT account creation step may not have finished before the email flow ran.

To test this theory, the professional uses the Background Scripts feature. They write a simple script to replicate the query:

var gr = new GlideRecord('sys_user');
gr.get('sys_id_of_new_employee');
gs.info('User found: ' + gr.isValidRecord());

They run it and see 'User found: false'. So the record is indeed missing at the time the flow runs. They now need to adjust the flow to wait for the account creation to complete. They add a 'Wait for condition' step before the email action, checking if the user record exists.

To be sure no other changes broke the flow, they also use version comparison. They go to the flow's record, right-click the header, and select 'Show versions'. They compare the current version with the one from last Friday. They see that a colleague added a new condition to the IT account creation step that now runs asynchronously, causing the delay. The professional rolls back that change temporarily and tests again. This time the email sends correctly.

Finally, they run a regression test: they create a new test employee record in the development instance, run the full flow, and verify that the email is sent, the desk assignment is created, and the HR record is updated. All pass.

The key takeaway for the IT professional is that troubleshooting is methodical: always start with logs, isolate the exact error, test with background scripts, check version history, and verify fixes with regression tests. This approach minimises downtime and prevents future breakage.

## Exam focus

The SNOW-CAD exam tests your understanding of application testing and troubleshooting primarily through scenario-based multiple-choice questions. You will not be asked to write code, but you must interpret logs, identify tools, and choose the correct troubleshooting sequence.

The exam focuses on these core topics:

- System Logs: you must know where to find them, the different log types (Error, Warning, Info), and how to interpret a log entry. A typical question might show you a log snippet with an error message and ask what caused it.
- Debugging tools: you must know the difference between 'Debug' for scripts and 'Background Scripts' for isolated testing. A trap question will describe a scenario where you need to test a script but the options include 'Debug' and 'Background Scripts' – the correct answer depends on whether you need step-by-step tracing (Debug) or just to run the script once (Background Scripts).
- Business Rules and their impact: the exam loves to test your understanding that a Business Rule can silently modify data after a record is saved. If a record value changes after update, check Business Rules first.
- Application file versioning: you will be asked how to investigate a sudden change in behaviour. The correct answer is to compare application file versions.
- Troubleshooting sequence: a common question format is 'What is the first step when an app stops working?' The correct answer is always 'Check the system logs' – NOT 'Rebuild the app' or 'Call the user'.

Specific traps to watch for:

- They might list 'System Logs' and 'Audit Logs' as answer choices. Audit logs track who changed what record, not what code ran. The exam expects you to know the difference.
- They might offer 'Check the ACL' as a step when the problem is a missing record. ACLs control access, they do not create or delete records. Use ACLs only when the issue is 'user cannot see data' not 'data is missing'.
- They might describe a problem that is clearly a Business Rule issue but offer 'Update Set' as a solution. Update Sets package customisations, they do not fix bugs. The correct answer is to review the Business Rule.
- They might present a scenario where the error is 'null value' and ask which tool to use. The correct answer is 'Background Scripts' to test the query, not 'User Criteria'.

Key definitions to memorise:

- System Log: a record of events generated by the system. Found under System Logs menu.
- Debug: a mode that runs a script line by line, showing variable values.
- Background Scripts: a tool to execute Servicenow scripts in a sandbox without impacting live data.
- Business Rule: a server-side script that runs on a database action (insert, update, delete, query).
- Application File: a component of your application, including scripts, tables, and forms.
- Version comparison: a feature to see differences between two versions of an application file.

Finally, the exam expects you to understand the 'Fail Fast' principle: when troubleshooting, the most efficient path is to check logs immediately, narrow down the time frame, and replicate the error in a controlled environment (like background scripts) before making changes. Guessing without evidence is a trap that costs time.

## Step by step

1. **Identify the symptom** — Get a clear description from the user of what is wrong. For example, 'The approval email is not being sent when a request is approved.' This defines the scope of your investigation.
2. **Check system logs** — Navigate to System Logs > System Log > All. Filter by the time of the reported issue and look for any Error or Warning entries related to the app or process. This step gives you the first concrete clue.
3. **Replicate the issue in a safe environment** — Use Background Scripts or a development instance to reproduce the exact steps the user took. This confirms the problem is not a one-time glitch and gives you control over the testing environment.
4. **Inspect the relevant Business Rules and Flows** — Identify any automated processes that run on the same record action (save, update, delete). Disable them one at a time to see if the problem disappears, isolating the culprit.
5. **Use Debug to step through the problematic script** — Activate Debug on the specific script identified in the logs. Run the process again and watch the variables change. Pinpoint the exact line where the logic diverges from what you expect.
6. **Fix and regression test** — Apply your fix in the development instance. Then run a full test of the app – including features not directly related to the original bug – to ensure no other functionality is broken.
7. **Document the root cause and solution** — Write a short note in the application's 'Update Set' or a knowledge article explaining what caused the error and how you fixed it. This helps future developers and prevents repeating the same mistake.

## Comparisons

### System Logs vs Debug Tool

**System Logs:**
- Shows all events (info, warning, error) that occur across the system.
- Used to find the initial clue about what went wrong.
- Cannot show variable values; only shows error messages and timestamps.

**Debug Tool:**
- Runs a single script step-by-step, showing variable values.
- Used to understand the exact logic flow after a clue is found.
- Only works when you specifically activate it on a script; it is not always on.

### Background Scripts vs Debug Tool

**Background Scripts:**
- Runs scripts in a sandbox without debugging step-by-step.
- Good for testing a query or function quickly.
- Output is printed to the screen; you cannot pause mid-execution.

**Debug Tool:**
- Runs scripts with line-by-line stepping and variable inspection.
- Good for finding subtle logic errors in complex scripts.
- You can pause, inspect, and continue execution at any line.

### Business Rule vs ACL (Access Control List)

**Business Rule:**
- Runs on database actions (insert, update, delete, query).
- Can modify data or calculate values.
- Triggers automatically when a record is saved.

**ACL (Access Control List):**
- Controls who can read, write, create, or delete records.
- Does not change data values.
- Applies when a user tries to access a record, not on every database event.

### Unit Testing vs Integration Testing

**Unit Testing:**
- Tests a single function or script in isolation.
- Quick to run; focuses on individual correctness.
- Cannot detect issues that arise when components interact.

**Integration Testing:**
- Tests how multiple components work together (e.g., script + email notification).
- Slower to set up; focuses on end-to-end behaviour.
- Catches issues like missing data passing between components.

## Diagram

_A flowchart showing the troubleshooting process from user report to fix deployment, emphasising logs, background scripts, and debug as key steps._

```mermaid
flowchart TD
    A[User reports issue] --> B[Check System Logs]
    B --> C{Error message found?}
    C -- Yes --> D[Identify error source]
    C -- No --> E[Identify symptom more precisely]
    D --> F[Open Background Scripts to replicate]
    F --> G[Use Debug on relevant script]
    G --> H[Find root cause]
    H --> I[Apply fix in dev instance]
    I --> J[Run regression tests]
    J --> K[All tests pass?]
    K -- Yes --> L[Deploy to test environment]
    K -- No --> H
```

## Common misconceptions

- **Misconception:** If my app works in a development instance, it will work the same way in production. **Reality:** Different instances may have different configurations, different data, and different ACL rules. Always test in a production-like environment before deploying. (Beginners often assume that code runs identically everywhere, but ServiceNow instances can have different system properties, scheduled jobs, or user permissions that change behaviour.)
- **Misconception:** The system logs only show errors, so if there is no error message, everything is fine. **Reality:** System logs show Informational, Warning, and Error levels. A missing information log might indicate a script did not run at all, which is also a problem. (New developers think of logs as only for errors, but they are equally useful for confirming that code executed as expected.)
- **Misconception:** If I fix a bug by changing a script, I do not need to test anything else because the fix is local. **Reality:** A single script change can affect other parts of the application through shared functions, global variables, or cascading Business Rules. Always run regression tests. (This mistake comes from thinking of code as isolated. In ServiceNow, many scripts interact via GlideRecord, events, or flows, so one change can trigger unintended side effects.)
- **Misconception:** The 'Debug' tool is only for ServiceNow administrators, not for developers. **Reality:** The Debug tool is a core developer feature for stepping through custom scripts and finding logic errors. It is one of the most important tools in a developer's toolkit. (Some beginners confuse 'debug' with 'admin only' because they have not used it yet. The exam explicitly tests your knowledge of debug as a developer tool.)
- **Misconception:** If an error message says 'security constraint', the problem is always an ACL. **Reality:** 'Security constraint' errors can also be caused by a missing role, a module access rule, or even a script that tries to access a table without enough authorisation. ACL is only one possibility. (The phrase 'security' misleads beginners into jumping to ACLs without checking other security layers like roles or module access.)

## Key takeaways

- Always start troubleshooting by checking the system logs; they show what actually happened and save hours of guesswork.
- Use Background Scripts to test code in isolation without modifying live data or triggering side effects.
- Debug mode lets you step through a script line by line to see variable values, revealing exactly where a calculation goes wrong.
- Business Rules can silently change data after a record is saved; if values look different than expected, review related Business Rules first.
- Application file version comparison helps you identify which recent change broke a feature by showing you the exact difference between versions.
- System logs have three levels: Informational (success), Warning (potential issue), and Error (failure) – all three are useful for diagnosis.
- A 'null' error almost always means a record or field was not found; verify your GlideRecord query returns the expected data.
- Regression testing after any fix is essential because a change in one script can break another script that depends on the same data or function.

## FAQ

**Where do I find system logs in ServiceNow?**

Go to 'System Logs' in the application navigator (left menu). Then choose 'System Log > All' to see all events. You can filter by date, type (Error, Warning, Info), and source.

**What is the difference between Debug and Background Scripts?**

Debug allows you to step through a specific script line by line, seeing every variable as it changes. Background Scripts let you run arbitrary scripts in a sandbox without debugging step-by-step. Use Debug for detailed analysis, Background Scripts for quick tests.

**Can I debug a Business Rule?**

Yes. Open the Business Rule in the UI, then use the 'Debug' button at the top of the form. This will run the rule in debug mode the next time the triggering event occurs (e.g., when you save a record).

**Why do I see a 'null' error when I run my script?**

A 'null' error means your script is trying to read a property from an object that does not exist – often a record that was not found. Check your GlideRecord query's get() method to ensure it returns a valid record before accessing fields.

**How do I check which version of a script changed recently?**

Open the script or application file record. Right-click on the header (where the name appears) and select 'Show Versions'. You can then compare any two versions to see the differences.

**What should I do if a flow or workflow stops working after an update?**

First, check the system logs for errors during the flow execution. Then, open the flow in Flow Designer and verify each step's configuration. Finally, compare the flow's current version to a previous working version using 'Show Versions'.

**Is a 'Warning' log a serious problem?**

Not always, but warnings indicate something unexpected happened that may not be critical yet. Investigate warnings related to your app as they can be early signs of a bug or misconfiguration.

## Check your understanding

1. **What is the first tool you should check when troubleshooting a broken application feature?**

   Answer: The System Logs (System Log > All) to look for error or warning messages that pinpoint the problem.

2. **When should you use the Debug tool instead of Background Scripts?**

   Answer: Use Debug when you need to step through a script line by line to see exactly where a variable assumes an unexpected value. Background Scripts are for quick isolated tests that do not require step-by-step tracing.

3. **A user complains that a field value changes after they save a record. What is the most likely cause?**

   Answer: A Business Rule running on update is modifying the field. Check the Business Rules associated with the table.

4. **How can you see what changed between the current version of a script and a previous version?**

   Answer: Open the script record, right-click the header, select 'Show Versions', and compare the two versions using the UI.

5. **What does a 'null' error in a script typically indicate?**

   Answer: The script is trying to access a property of an object (like a record) that does not exist. For example, calling .getField() on a null GlideRecord.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/servicenow-cad/application-testing-and-troubleshooting