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.
Jump to a section
A simple way to picture Application Testing and Troubleshooting
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
These come up on the exam all the time. Here's how to tell them apart.
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
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
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
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.
Mistake
If my app works in a development instance, it will work the same way in production.
Correct
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.
Mistake
The system logs only show errors, so if there is no error message, everything is fine.
Correct
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.
Mistake
If I fix a bug by changing a script, I do not need to test anything else because the fix is local.
Correct
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.
Mistake
The 'Debug' tool is only for ServiceNow administrators, not for developers.
Correct
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.
Mistake
If an error message says 'security constraint', the problem is always an ACL.
Correct
'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.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
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.
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.
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).
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.
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.
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'.
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.
You've finished Application Testing and Troubleshooting. Continue through the SNOW-CAD study guide to build a complete picture of the exam.
Done with this chapter?