Now that the development is complete, for our example application, we will look at testing it. The main aspect of our application we need to look at is the script we created. 

However, it is always important to check every aspect of your application, especially against the requirements of the stakeholders that the application will be for.

Some dummy data has been added so that we can check our script is working correctly in the user access and access tables. The User table is populated with users in the ServiceNow baseline system that you can use when testing applications. 

We can see the entries in the User Access table in the following figure:

As can be seen in Figure 12.20, there are two users that have access to Server A100. This means that if we try to select these users when Server A100 is selected, we should not be able to pick those users.

Let's check if this is possible or not:

As we can see in the previous figure, after searching for Fred, we do not see Fred Luddy, which is a good sign and it tells us that our scripted reference qualifier is working correctly.

As part of testing, we will also remove the access to Server A100 from Fred Luddy and check that he is then available for selection when creating a user access records for Service A100. With the code we have created, this test also passes and meets the requirements.

There are further tests you can perform, and the level of testing a developer undertakes is often dependent on a number of variables. This can include the impact of the new application on current applications, and whether testing is performed by a separate testing team or not. We will complete testing for our example user access application here.

When testing your applications, choose a level of testing suitable for your needs, and remember to test edge cases if you think that they may bring about testing failures.