I am constantly looking for ways to make platform upgrades easier and less cumbersome for my organization and clients. Adhering to best practices when developing solutions is one step towards making upgrades easy, though there is still a long way to go. System upgrades will likely never be completely stress-free (I'm looking at you, account executives) but another way to make upgrades easier is to test your existing procedures to verify they still work after an upgrade. Manual testing is great, but it takes a lot of manpower that could otherwise be used for more fulfilling work. There are many tools that can be used to automate the testing process, but many (most?) require infrastructure and technical expertise.
ServiceNow's Automated Test Framework (ATF) may be a great solution for organizations without existing automated testing infrastructure and technical expertise. Using straight-forward, step-by-step configuration, a ServiceNow admin (or ATF admin) can build tests against common scenarios across the platform. Automating the testing process can be used for each release or even daily if an organization's Agile process allows daily releases. I think ATF is especially useful for identifying what works and what doesn't during platform upgrades.
High-level Features
ServiceNow's Automated Test Framework has many features that allow for robust testing of configurations and customizations. Here are the highlights as I see them:
(NOTE: This was written against a Kingston instance, so features in prior and future versions may vary)
- Client-side
- Create new records
- Update existing records
- Validate field values
- Validate field states (read-only, mandatory)
- "Click" UI Actions
- Server-side
- Impersonate users
- Query records
- Validate field values
- Insert/update/delete records
- Service Catalog
- Search for catalog items and record producers
- Set variables
- Validate variable values
- Validate variable states (read-only, mandatory)
- Submit a catalog item or record producer
(There are also capabilities for testing REST, but I recommend understanding the high-level features before getting into advanced topics, such as this.)
Getting Started
ATF is likely already installed in any instance running Istanbul or later. If not, it can be activated from the System Definition > Plugins module. While it may be installed in Production, ATF should always run in sub-production instances. AFT is submitting real records and checking real data, which means that real notifications could be sent to users if it is used in a production environment.
Hopefully organizations have process owners and those process owners have defined their processes and procedures. Those documents (or hopefully ServiceNow KB articles) are great places to identify low-hanging fruit when it comes to automating the testing process. If an organization leverages stories for defining ServiceNow features, these are also great places to identify what can be automated.
As an example, a story may say, "As a Service Desk user, I want to prioritize incidents using impact and urgency so I can consistently prioritize work." The story may then detail the specific combinations of impact and urgency that will achieve each priority. This is a prime example of a feature that can be automatically tested. The idea with automating this test is to make sure that when you set Impact to X and Urgency to X, you get Priority X. This particular test scenario can be built using 100% configuration and 0% code. A series of "set field values" and "validate field values" steps is just about all you need to make this happen.
(Check out ServiceNow's Docs site to get the official rundown on ATF: Getting Started with the Automated Test Framework)
Digging Deeper
The key components of ATF are:
- Tests
- Test steps
- Test runners
- Test results
Tests are the series of steps that validate the behavior of the environment.
Test steps are unique activities that a) verify a certain aspect of an environment behaves as expected, b) show where the environment does not behave as expected, or c) enables a future step to perform a or b.
Test runners are the browser windows where tests are performed. These can be in a separate window on your computer, in a virtual machine (local or remote), or on a server somewhere. Test runners can be in any browser of your choosing, though there does not yet appear to be a way to simulate a mobile browser, but surely that's coming.
Test results are the output of running a test. Each test result shows the test steps that were completed, the outcome of each tech step, and screenshots (for all steps or only failed steps, if enabled in the test runner).
Those are the four components needed to begin test automation in ServiceNow. There are other components, such as automated test suites, automated test suite schedules, and custom test steps. I may write future articles that detail these as well as the actual building, batching, and scheduling of tests. (Please mark "Helpful" or leave a comment if you find this useful!)
Wrapping Things Up
Imagine cutting the platform upgrade process from a month or more to just a few weeks by automatically understanding what works and what doesn't. As stated previously, ATF won't solve all of the platform upgrade woes and there is still a place for manual testing, but ATF will definitely help. It's also not a process that ever ends. There's no "done" with ATF. There is always something more to test, refine, repeat. The most important part is to just get started.
