Service Virtualization

Stand out with a layered test approach.

By Chris Kraus, Sr. Principal Product Manager

Remember back in the day when mainframe testing was simple. UI calculations and persistence were all in one layer; all errors reported back to the 3270 screen and trained employees were the users of applications. With the introduction of more powerful client workstations, things got a bit more complicated and we had to move from the CUI to the GUI. Most business logic was in the GUI, errors were still presented in the UI and users were trained on how to use the UI.

Oh… have times changed. Mobile applications and the consumer now rule and not only do we have so much more to test but less time to do it. In order to keep up, functional, regression and performance testing must start before development is done. Testing the new fashioned way means moving the test closer to the logic and focusing on the various application layers.

By moving the test closer to the code you can:

• Distribute the tests across the architecture
• Remove layers of complexity by testing as close to the logic as possible
• Start functional testing before development is complete
• Decompose big response times into little pieces

Key questions you should ask when looking at the layers include:

• What business rules and validation are at the mobile layer?
• Are the API/Service end-points changing data?
• Is all of the Enterprise Service Bus (ESB) data on the wire?
• Backend systems – what is old is new or is it new?

In addition to asking the above, there are additional considerations you’ll want to take into account when testing the various layers:

• Mobile and HTML 5 layers – Validate the data on the screen for formatting, alignment, input validation and enabling functions. Evaluate how the code is performing on the device. Recognize that traditionally brittle small changes in UI’s will increase the time required to maintain tests.
  
  
• API and Service Delivery layers – You’ll need to take a modern approach to testing the UI (SOAP XML, REST JSON, HTTP & Message Queue’s). Orchestrate multiple testing service calls to accomplish a requirement. Keep in mind API calls are less brittle than UI tests and should be used wherever possible. Run nonfunctional testing to understand composite response times.
  
  
• Enterprise Service Bus (ESB) – The ESB represents “all the wires in the house”. It’s usually the single central point of blame and the hardest system to test. You’ll need data on the wire to test, you may need to simulate the system to do this. In addition, you’ll need specific dependent data to test the transformations, and simulations then to match the required transformations. There maybe 1000s of combinations of data to test.
  
  
• Systems of Record – What’s old is new and more new! Here we see business functionality turned into composite services or APIs, service decomposition becomes important. You’ll need to build out regresses for undocumented systems. Watch closely for failures, failures many times this low in the stack can be gobbled up by an asynchronous process. Legacy systems behind the ESB also have their own set of testing challenges:
  • Data on the wire is needed (and it probably won’t be pretty)
  • Custom layouts for Cobol copybooks, CSV, and EJBs
  • Non-human readable data (Hello… Java object or CORBA)
  • Business logic and persistence and combined functionality

Now that we know what we are testing, how do we do it faster? The answer is automation. The two biggest exceptions to test automation typically include: “look and feel” and graphical differences of images. Other than that, I recommend automating everything you can.

CA offers a comprehensive suite of test automation solutions. For the purpose of this discussion, I’d like to focus on how CA Application Test can help you update your test “style”.  Features that align to the considerations discussed in this article include:

• Mobile – Using CA Application test you can validate the data on screen using the record and playback functionality specific to mobile devices like iOS and Android. Get away from brittle testing, write your test once and run anywhere (locally device, cloud attached device or a simulator). Execute tests to test code functionality performance.
• Service Testing – Since service testing is all about testing the data on the wire, you need to use a tool like CA Application Test to put the data on the wire and get it off. With CA Application Test one test can be used for functional, regression and non-functional testing.
• API Testing – CA Application Test includes a graphical visualizer for JSON  based payloads and path generation.

• Enterprise Service Bus – CA Application Test supports industry standards and customer protocols for ESB. The secret sauce to CA testing’s approach for ESBs is CA Service Virtualization. Virtualized services can be used to stabilize the environment and prevent false failures from occurring. Regression can also be a huge problem for ESBs, CA Application Insight addresses this by creating the volumes of tests needed to achieve the necessary testing velocity.

For organizations that have been around for a while and can’t let go of that old college sweater. CA Application Test has the ability to test legacy back-end systems. It is one of the few solutions in the market that can invoke and verify at every layer and enable you to test the new fashioned way!

If you’re looking for more ways to update your DevTest style, try Service Virtualization. The best place to learn more about Service Virtualization is at www.servicevirtualization.com.

For Question answer session check out CAW2015 Session Catalog and search for DO4X80E

Tue November 17