Rule of ServiceNow’s Automated Testing Framework (ATF): Keep It Simple

  • April 01, 2021
Software engineering developer writing code laptop

“KIS”, Keep It Simple, is an acronym my manager first introduced during a one-on-one and it has stuck with me – especially when I first started working with ServiceNow’s Automated Test Framework (ATF). Today, I’m sharing some key lessons learned for how I make the most of ServiceNow’s ATF, a platform application used to automate tests performed to verify apps, customizations or configurations.

Minimizing ATF testing steps for future efficiencies

In regards to ATF, “KIS” refers to minimizing test steps, which results in faster test runs and less future maintenance. I’ve had multiple clients provide test scripts with repetitive steps, but in reality, you should only have to test something once.

For example, there isn’t a need to repeat a test step to check if a field is mandatory in every test you create for a catalog item. Another rule to keeping ATF simple? Only build tests for functionality that is unique to the instance, not out of box.

Since I first started with ATF, I have significantly simplified the way I build tests and test suites. For example, if I am building an ATF for a catalog item, I first create a test suite for the catalog item that contains multiple tests. The first test I create would be for form validation. This checks for mandatory variables, variable visibility conditioned on other variables, etc. The next tests would be all possible paths that could happen based on the workflow or flow.

Once successful, tests are easy to copy and modify, but they can still provide roadblocks along the way. The new Custom UI test steps are one specific example. I have found that these test steps work great for modals such as transferring or suspending work on an HR case, but do not retrieve components for the other modals such as the risk assessment for Change Requests or HR Case Creation UI page. I take these test steps to suspend work on an HR case. They should be added after creating a user and creating an HR case.

  1. Open the existing HR case
  2. Click a UI Action, then click on the Suspend UI Action
  3. Set Component Values (Custom UI). When you select this step, you have to retrieve the components on the UI page. Once components are retrieved, select the field(s) and set the value(s). It helps to navigate to the UI page and view which component you’re trying to set, otherwise the ATF page inspector is useful to help identify the component.
  4. Click Component (Custom UI). Once you have set the values, this step allows you to click the component: ‘Button

Steps are different for HR & risk assessment cases

Since these steps worked so well for HR Cases, I initially assumed they would work for Risk Assessments for Change Requests because it is also a Glide Modal, but boy was I wrong. After extensive research and testing, along with the helping hand of an angel sent from heaven (my wonderful team member Chris), we were able to put together a script that worked for our client.

ATF in Action

In the test, after inserting a Change Request record, we also added a Run Server Side Script step with the following code. When running the test, this server-side script does take a bit of time, but with some patience the script will insert a Risk Assessment and update the risk/impact on the Change Request record without issues.

(function(outputs, steps, stepResult, assertEqual) {
//get change record
var changeID = steps('sys id of the test step where the change request was created').record_id;
var justCreatedGR = new GlideRecord('change_request');
if (justCreatedGR.get(changeID)) {
//create assessment
var metricType = 'sys id of the metric type';
var asmtUtils = new AssessmentUtils();
var assessmentDetails = asmtUtils.createAssessments(metricType,changeID, 
var asmtInstanceSysId = assessmentDetails[0];
//set response in assessment questions
var setResponse = new GlideRecord('asmt_assessment_instance_question');
setResponse.addQuery('instance', asmtInstanceSysId);
while ( {
//"CRS - Executing while loop");
if ( == 'Name of Assessment Question') {
setResponse.value = 0;
} else if ( == 'Name of Assessment Question') {
setResponse.value = 0;
} else if ( == 'Name of Assessment Question') {
setResponse.value = 0;
//set assessment to complete and link to task id
var justUpdatedInst = new GlideRecord('asmt_assessment_instance');
if (justUpdatedInst.get(asmtInstanceSysId)) {"CK - Found Assessment Instance SysId: " + asmtInstanceSysId);
justUpdatedInst.state = "complete";
justUpdatedInst.task_id = changeID;
//calculate assessment result and update change record with calculated risk
var calculatedRisk = new ChangeRiskAsmt().calculateRisk(justCreatedGR);
if (calculatedRisk.riskUpdated) {
stepResult.setOutputMessage("calculatedRisk.risk " + calculatedRisk.risk);
justCreatedGR.risk = calculatedRisk.risk;
return true; // pass the step
} else {
stepResult.setOutputMessage("Failed to calculate risk");
return false; // fail the step
})(outputs, steps, stepResult, assertEqual);

Without a doubt, ATF is becoming more and more popular amongst our clients. Although building tests takes a significant amount of time, especially for more complex functionality, its benefits are undeniably valuable. I hope you can use these tips to streamline your testing, and when in doubt, remember to KIS.

To learn more about ATF and its new features in the platform’s latest release, contact us for a complementary demo.