API Testing and Message Testing

Introduction: The aim of this document is to enumerate the various key points related to API and message testing in software applications. The knowledge has been culled form information available over Internet, experience gained from the projects executed by el! and some inferences. The information should help in future projects, for collection of right information from the customer, planning and identifying right resources, design of test cases and ease of execution. "astly but not the least, explore and come out with some tool or frame work to enhance the productivity in all phases of the Test "ife cycle and value add to the customers. Objectives: #. &. '. (. +. $nough understanding of the test domain, and facilitate the test team to collect test re%uirements efficiently and uniformly. To estimate the effort and resources realistically To identify right resource with right skills To identify the technology gaps ahead, and take appropriate corrective)"ike Training* actions To help in ,esigning of the test cases, and enhance the productivity of the test cases

API Testing and message level testing usually forms part of -ystem Integration Testing. In particular message level testing. .sually messages are tested when all the interfaces are not ready. Testing at message level helps in finding the bugs in different interfaces early. Activities: The following activities are envisaged, for testing of API/s and 0essage level testing -ystem study 1 Proposal Test strategy Test Plan Test case Design Test $xecution Tool usage ,efect reporting

API Testing: - Guide line for Test case design API Testing could be classified in two ways 2ontext based )As per the re%uirements of the applications usage of the API*. The following guide the user in design of test cases. 3unctional re%uirements or use case document or functional specification -tudy of the detailed design of the API to be tested )$ speak and 4$-* Interfaces could 5ava classes

Interfaces could be $56/s Interfaces could be 277 or 8277 classes Interfaces could be 29 6A objects Interfaces could be proprietary objects of -AP, -I$6"$, 6AA: etc "anguage in which the interfaces are written )$;speak 1 4$-* "anguage used is 5ava 2hoose the language in which client programs to be written )4$-* 2lient programs could be a single class or could a client for $56 2hoosing of tools to compile client programs )4$-* <ow the parameters are passed to the interface and how the results or return values from the interface are collected for verification )4$-* The parameter values shall be designed based on functionality and passed to the interface using client programs. 3urther test cases= Test scripts can be designed based on formal test case design techni%ues The results can be collected in the form of >0" or Text formats $xplore the possibility of using formal test case design techni%ues for input values of the parameters 2ross reference matrix for each interface to be tested ,esign of test cases, based on the target interfaces either single or multiple )when testing of single interface is not possible due to application architecture or dependency. ,esign of business scenarios based on application functional re%uirements, not based on interface functionality ,esign of the client programs. 4e can think of designing a client program template, which can be used with minimum modification, like changing the method names and parameter names. This can find way in to our ?0 tool.

Test API objects for full functionality e%uirements or functionality of the API. 0eans intended use of the API ,etailed design of the API Parameters and their valid ranges. Test cases shall be designed using formal techni%ues for input values ,eveloping scripts )to assign input values to parameters and collect return values*. The scripts shall be more generic and can be modified with minimal effort. This enable the tester to use these scripts for testing more API/s in less time. Take help of code coverage tools to verify that the client programs are covering the complete functionality of the Interface It also helps in identifying unreachable paths in the interface

Message Testing: The following are tested at this level 0essage flow from point to point as expected 2orrectness of the data being passed through the message 2orrectness of the functionality of the interface, triggered by the data received through the message

&

Message Level Testing Guide lines for Test case design 3unctionality=usecase of the application, that triggers the message flow .seful to design business scenarios .seful to design test scenarios .seful to design test cases to trigger messages across the subsystems Testing re%uirements 0essage formats )Text files, >0"* 4ill help in designing the test cases)4hen test case itself is an >0" message or a text file* 0essage flow across and between systems If different formats are used across sub systems, Interface control document will help in design of test scenarios and test cases. 3ormal techni%ues can be used to design test cases If any middleware is part of the system, functionality of the middleware also triggers the test scenarios) 2ould be :egative or Positive* ,T,/s in case of >0" messages ,evelopment schedule of the various interfaces and systems to arrive at test strategy Test methodology can be designed depending on the availability of the interfaces for testing. ,ecision to develop a test harness to test interfaces can be taken .sage of %ueue managers 3amiliarity of %ueue managers helps in test execution. .sually verification points )by extracting the message from the %ueues* and %uite useful for debugging and pinpointing the error in the message. Application architecture and environment Test cases may be designed to verify the message standards -4I3T )-ociety 3or 4orldwide Interbank 3inancial Telecommunication* .: $,I3A2T ) .nited :ations $lectronic ,ata Interchange 3or Administration, 2ommerce and Transportation*

'