With Jessie Lissenden
In this article, we’ll be introducing the ServiceNow Automated Test Framework (ATF). We will cover a brief overview, some considerations for implementing ATF, running an out-of-the-box quick start test, interpreting the test results, and maintaining ATF during clones.
What is the Automated Test Framework (ATF)?
With ServiceNow ATF, you can create and run repeatable automated tests to verify the functionality of your ServiceNow applications and features. ATF tests can be run periodically as scheduled or on-demand after system changes. Think about every time you upgrade your instance. ATF can provide consistent documented testing and save hours of hand testing. If you are implementing ATF for the first time, there are some considerations to keep in mind. ATF is only intended for use in sub-production environments and preferably it should be run off-hours; this is because ATF rolls back any changes that are made at the end of each test, so there is some risk for data loss on record changes made asynchronously outside of ATF during the testing window. Tests need to be run in a desktop browser window without interruption. Lastly, ATF is not intended for test-driven development; this is because components need to already exist in your instance to configure ATF steps for them.
Running an ATF
To run a test, first you will need to enable ATF test execution. This property is disabled by default so that tests will not be run on production instances. To enable test execution on a subprod instance go to Automated Test Framework > Administration > Properties. The first property will allow you to execute tests and test suites, and the second property will allow you to schedule test suites if you want them to be run periodically. For this example, we already have both properties enabled, so let's look at some quick start test suites. For this demonstration, we are going to be looking at the incident management test suite. For a list of all available quick start tests, refer to the ServiceNow documentation.
To use a quick start test suite, or an individual quick start test, you will need to copy it. Quick start tests are read-only and inactive so that you don't modify the original record. If you haven't already copied it, a UI action to do so will appear in the top right corner, but since we’ve already copied it, we are going to go ahead and navigate to our copy of the incident management test suite. For this demo, we are going to run one test individually.
Before we run the test, let's look at some of these test steps (to take a closer look at the steps, please refer to 3:21 in the video). If you're creating a new ATF test, it is best practice to start out by impersonating an ATF-specific user or creating a new user within the test to impersonate, which will be rolled back at the end. This helps mitigate some of the risk of rolling back record changes made outside of ATF during the testing window. It is also best practice to validate any records that were created or updated during the test.
Overview of the Test
Let's go ahead and click Run Test. You will be prompted to select or create a new client test runner. This is the browser window in which the test will be executed, and it needs to remain open for the duration of the test. Click Run Test on this window. The following screen is the client test runner window, where you can watch the test execute in real-time. Screenshots of each step are also saved to the test results.
For an overview of the test in progress, you can navigate to the main window. When the test is complete you can click Go to Result to look at the test result record. In our example, you can see that this test was completed successfully, and this record will be retained for 60 days by default, with an option to retain it indefinitely. There's information about the browser in which the test was run, which is important for compatibility testing. You can view more details about each test step in the step results related list.
Looking at Results for a Failed Test
Let's look at the results for a failed test; this is a test that was already run, and you can see right away that the status is failure. It also provides information on the failing step; in this case, it was unable to find a UI action, and there's also a screenshot included of the failure. Note that in the step results, any steps that would have occurred after the failure are skipped. Keep in mind that quick start tests suites and the individual tests are configured for out-of-the-box applications and demo data. If you need to reconfigure quick start tests to work with your instance, you will need to make those changes to your copies of the tests.
Before we end, let’s talk about maintenance because it may not be intuitive compared to other applications. Even though ATF tests should not be run on production instances, it is currently considered best practice to promote ATF changes to production using update sets. This will ensure that ATF is preserved during clones. ServiceNow support has stated that ATF tables are not designed to be transferred to the target instance using the data preserver. Because of this, it is important that the test and test suite execution, as well as the scheduled test suite execution properties, remain disabled on the production instance.
Did you find this Introduction to Automated Testing Framework (ATF) in ServiceNow article helpful? Are you ready to start your journey with ServiceNow? If you want to find out more information about GlideFast Consulting and our ServiceNow implementation services, you can reach out to us here.
About GlideFast Consulting
GlideFast is a ServiceNow Elite Partner and professional services firm that provides tailored solutions and professional services for ServiceNow implementations, integrations, managed support services, application development, and training. Reach out to our team here.