Kasper Fehrend
>In thousands of enterprises, ServiceNow is the beating heart of daily operations. If something breaks, it will have effects across the business. The problem is that testing ServiceNow is a real time sink, which puts the platform’s agility at risk.
ServiceNow offers a leading platform for IT Service and Operations Management. For many ServiceNow clients, the platform is a cross-functional operational backbone, asit includes a wide range of applications for IT, security, customer service, HR, and more.
The platform's versatility is a major strength. However, it also makes it highly critical to verify that ServiceNow processes work as they should.
The problem is that testing ServiceNow processes properly is both difficult and a real-time sink. This is due to several things: How the platform is built, how ServiceNow releases new versions, and how customers use the platform. Let’s look at these issues separately.
The object model: Great for development, a challenge for governance
ServiceNow is built upon a solid object model. The elements that make up the various modules are easy to reuse when developing ServiceNow applications.
This creates a need to keep an overview of all changes, as they can have unforeseen consequences.
For example, if someone changes a field to be mandatory in one form, this change will affect all other forms that contain this field. It is not uncommon to have individual fields and tables being used in more than 50 places in the application.
Often, a Lead Developer is tasked with keeping an overview of all the changes made in ServiceNow development. This creates a process bottleneck and kills the agility that the ServiceNow platform comes with.
Having just one person with an overview of the entire system also comes with a significant risk: What happens when that person is no longer in that position?
Incoming system upgrade: Test, test, test!
ServiceNow releases major feature upgrades twice a year and, as a client, you are only allowed to skip one upgrade.
This means that at least once a year, upgrade panic kicks in, which involves testing, verifying, and understanding the new version. Sometimes it’s even necessary to bring in external consultants. These are costly activities, and in most cases, potential benefits will be far from making up for the cost.
In most companies using ServiceNow, even staff in business functions must do testing during system upgrades. They are the only ones fully understanding the processes to be tested and verified.
Customization growing out of control
The ServiceNow platform makes it easy to develop any kind of application without programming skills. This means that several roles across teams can participate in the development of an application.
Low dependency on costly developer resources is great, but it also means that the amount of customization can grow out of control.
ServiceNow provides some useful best practices for developing. However, in some cases, the recommendation is simply to create process documentation. This is the case when it comes to, for example, how to migrate sets of updates and how updates affect and depend on each other.
This increases the need for maintaining documents and doesn’t really help you adopt best practices for daily operations. With visual process automation , on the other hand, you can document processes while you automate them. >
Changes that affect the security of a ServiceNow system are an example of an area that is rarely verified as part of an upgrade. ServiceNow users have different privileges in different modules depending on their role.
This means that system changes can have unforeseen consequences from a security perspective. So, there's a great need to be able to test functionalities as different user roles.
ServiceNow never works alone
With its multiple integration points, the ServiceNow platform ties business operations together. Specifically, ServiceNow often orchestrates processes to and from other systems.
Examples of ServiceNow integrations include:
- Change requests are pushed from a DevOps pipeline through the ServiceNow REST API. When the request is approved, ServiceNow triggers deployment to a production environment.
- End-users place requests in the Service Catalog. ServiceNow then triggers robots to order hardware from web portals.
The amount of possible integrations makes ServiceNow a business-critical system. If the platform doesn't work, it will have a domino effect across business operations. This makes it vital to verify end-to-end processes that involve ServiceNow.
Test ServiceNow with intelligent automation
It's an advantage to have an easily customizable platform that takes care of business-critical processes from IT to HR. But ServiceNow users need to be aware of the pitfalls listed above.
To drive the most value with your ServiceNow platform, we recommend the following:
- Follow the best practices for ServiceNow development. This won’t solve all problems, but it will help you maintain an overview of the application. It ensures that customizations follow the same patterns.
- Free up resources across business functions by automating ServiceNow processes. Especially all the repetitive, resource-intensive, and risky operations related to system upgrades.
The Leapwork Automation Platform is a great fit for ServiceNow, for at least two reasons:
- A single Leapwork automation flow can span technologies, including ServiceNow, Windows, SAP, etc.
- As with ServiceNow, Leapwork is based on a vision that all users should be able to develop without having to program. With ServiceNow, users can build applications, with Leapwork, users can automate these applications.
Check out Leapwork's tutorials, out-of-the-box samples, and educational resources to get started with ServiceNow automation.
You can also download our whitepaper on ServiceNow Testing to get more in-depth knowledge on the topic.
