Automated Integration Testing Utility

[Mahira]

Hi all,

One of our customer is looking for an Automated Integration   Interface Testing   solution/utility .

Requirement is to perform regression testing on all the existing integration   interfaces   with ServiceNow. Integrations would be email integrations, ServiceNow to Remedy integrations, JDBC integrations etc

Whenever a new integration is ready for deployment "the integration solution" should cater to perform regression testing and provide the status of interface.

Some of the solutions that we could come up with is

Option1:

SOAP UI can be used to simulate the Web service Integration interfaces .

Options2:

Service Now SOAP message tests utility.

Option 3 :

Use any external testing tool like TOSCA.

I would like to hear from anyone who has done anything on these lines or give pointers on how this can be achieved.

Thanks in advance.

Regards,
Mahira

[a_kleemann]

Dear Mahira,

We use SOAP UI ourselves to manually verify the ServiceNow Webservice Interface during development.

But for regression testing we prefer automation.

From my point of view there are the following crucial points to be addressed. Please correct me if I misunderstood your requirements.

1.) ServiceNow Webserivce Interface based integrations

What I'd suggest is to use the Tosca Webservice Engine to directly access the Service Now webservice interface directly to validate data sent to the system.

Benefit is that you can easily scan the webservice interface with the Tosca XScan.

Through that approach you can update the modules without an technical impact on the Testcases, even if the interface changes when new database fields are added to the tables in ServiceNow.

We use a similar approach to automate regression tests for UI or Webservice triggered data changes in our customer projects.

2.) ServiceNow-Remedy integration

I don't know if you're doing a one time import or a sync between the two systems, but you can either automate both systems using their Webservice APIs or use a combination of Browser based and webserivce based automation.

It shouldn't take long to access Remedy REST/SOAP exposed methods (via the packaged Jetty web server) with the Tosca Webservice engine and do the same on the other side with ServiceNow.

You also could use the XBrowser Engine to fetch data from any web UI and verify it against the database of the other system.

Depends on your usecase though.

3.) E-Mail Integrations

You could either fetch the information directly from the ServiceNow Mail->Sent table and verify them against predefined values, or you can check them directly in a mail client.

We support Outlook (2007-2013) as Mail client. If you want to get detailed information take a look at our system requirements. (https://support.tricentis.com/community/manuals_detail.do?sysparm_document_key=u_webhelp,b2cc38b137a...)

4.) JDBC Integrations

I've no experience with that in particular, but with more details on how those are integrated in your environment and a specific use-case, I'm sure I can figure something out 😉

5.) Automatically trigger tests during SDLC

That thing is one I like the most. Over the past few years some of our consultants have met those requirement very often and came up with a solution called Continuous Integration to face it.

I always thought well, that sounds cool, but that can't be that impressive.

I was realy surprised when I first saw the solution that made it in our regular Product Release recently.

Tosca Continuous Integration enables you to trigger tests fully automated via your Build Server (e.g. Jenkins) and the Suite does the rest.

Check out our Manual Page on that issue: https://support.tricentis.com/community/manuals_detail.do?sysparm_document_key=u_webhelp,98cc38b137a...

6.) ServiceNow development cycles

Since we use ServiceNow internally for our Support organisation we've developed a lot of integrations and applications ourselves.

During that we encountered that one of the most challenging tasks is to coordinate tests with udate set imports from dev to live instances.

From our experience, working with two ServiceNow instances leads to a gap of functionality between our live and our development instance.

We have a 2 months release cycle where we close the gap by cloning the live instance back to the dev instance with each release.

To ensure that there are no issues with the changes from the dev instance merged to the live system, we schedule smoke tests on the live instance after update set import.

Because of the requirement to separate Live from Development/Test data and the fact that ServiceNow only transfers configuration and functional data from one instance to another using the update sets, separate test data is necessary to test the different instances.

This is a bit tricky since one should not mess with the live system.

We achieved the scenario to maintain and administer different business data sets for live and dev instances using our Tosca TDM and Test Case instantiation approach.

Using that we can utilize the same Test Cases on different instance with dedicated test data.

Important thing is to automatically flag, remove or otherwise treat the livesystem to ensure no testdata is there.

Works great, but gives me a headache every release 😉

Hope that answers your question and helped you out a bit.

If you or one of the other esteemed readers have any questions about that, I'd gladly answer them

Best,

Alexander

[rahyad911]

Hi Alex,

can you share me further inputs on how we can integrate SNOW with Tosco

[Mahira]

Thank you so much Alexander for the detailed reply. I will surely get in touch with you in case if I have any questions

[tim_leigh]

Hi Mahira,

If you haven't already, you can also check out CapIO, an automated testing tool specifically built for ServiceNow.   Based on what you're looking for, it automatically runs regression testing on new and existing applications as well as assists with functional testing for new development.   You can see more at the attached link, or feel free to DM me for more info.