Web Services have become a preferred method in creating web applications. It allows for development to encapsulate the production of the software on a piecemeal basis. In this way, you can simply add new functionality without impeding with code that has already been developed. From a QA perspective, it allows testing to proceed as new Web Service are created. In most cases, once a Web Services has been created and tested QA does not need to retest those services unless a change has been made to the Web Service.
What is Web Service Testing? And, How To Test It.
Usually, Software QA gets involved not only in testing an application but also in conducting performance testing. In terms of performance testing, early testing provides the development team time to identify issues with an application’s performance. What we have noticed is that those that employ Web Service have the easiest time in getting the application tested and once tested dealing with application performance issues.
Why? From a quality perspective, Web Service allows for each “method” to be tested individually. Through its interface, each field in the method constrains the type of data that can be entered. This allows a test team to virtually specify the total number of test cases that are necessary. This includes both positive and negative types of testing.
Functional and performance testing can be conducted using different methods. Traditionally this type of testing has been conducted by constraining testing to various “moments” where it is deemed the most important. Examples include determining how many users can log in at the time. These tests can be constrained by increments. For example, what is the response time if one thousand users log in at the same time. Then increment this can be elevated to 2,000, etc.
From a performance perspective, each of the methods can be tested separately. Because the testing can be conducted from the level of a “method” then the results of a “method” allow for the development team to hone on underlying issues. In other words, once the results are reported the development team can quickly determine where there may be issues and focus on those methods that look problematic.
Web Service has two opposing types of application programming interfaces (aka API’s). One is called SOAP (Simple Object Access Protocol) and the other REST (Representational State Transfer). We do not want to get into the battles between those who prefer one over the other but want to explain how they are used in terms of testing. As explained before you can test them at the method level (one operation) or from a scenario level. In fact, from a QA perspective you would want to test them at both levels; first at the method level and then from the creation of scenarios. The scenarios many times will emulate how the application will be developed, so it is important to know which methods will be used in the application and in what sequence. Ultimately, this is how the entire application gets tested.
The most popular API is Rest. One of the main reasons is because REST allows for many types of data types and data formats like plain text, HTML, XML, and JSON. While SOAP only uses XML. However, SOAP is excellent from the security level via the WS-Security extension.
Testing Web Services
So, what is the process that makes the use of Web Service an approach for better quality and better performance? Maybe the best way to explain is to show this by creating a sample application that is very simple for demonstration purposes.
Let us say you have a web application that has the following features: User, User Role or User Profile, an organization, and the capability to Login and Logout. For each of these features, we would want to utilize the four basic functions for handling data such as create, read, update and delete (also known as “CRUD” for those familiar with databases). For “Users” we would want to perform functions like create a user, read a user’s information, update a user (or change information on a user) and delete a user.
So, from a Web Services perspective, we could create four methods (as explained above) or functions in the following manner: createUser, readUser, updateUser and deleteUser. Each of these methods would contain fields where data can be entered or modified.
Let us look at createUser. One could imagine the following fields would be available: First Name, Last Name, Street Address, City, State, ZipCode, and US Citizen. The first five fields would be alphanumeric fields. The ZipCode would be a numeric field. And the US_Citizen field would be a Boolean field.
To test this one would create positive tests for each of the fields, in other words, enter data that is constrained but appropriate for the fields. For the negative tests, we would enter data that is not appropriate for that each field type. For the alphanumeric fields, we could enter a Boolean value. For the (Zipcode) field we would enter a letter and Boolean alphanumeric value. We would, then, do the same type of testing for all other methods. How is this testing different than for other types of applications? It is different because we are testing the constraints governed by the method. This means that the methods contain a limited range of functionality. Therefore, from a positive and negative perspective, you have tested every possible combination.
There are other benefits to Web Services testing in that a tester can create scenarios by combining methods into suites. In this case, you could log in, create a user, give the user a role, assign a user to an organization and then log out.
One other advantage of this scenario is that you can create a matrix of dependent methods. For instance, you cannot create a user role until you have created a user.
Web Services Performance Testing Tools
Two tools come to mind in the testing of Web Service – SoapUi and Postman. While SoapUi can accommodate both SOAP and REST, Postman is essentially a REST client. Both tools allow for testing to occur at the method level and the scenario level. Also, both allow for validations to occur (pass or fail). Both have free (open source) products but also applications with more convenient interfaces but at a price.
Web Service from the Performance Perspective
Many of the advantages of Web Service for QA are the same when measuring an application’s performance. The main advantage of using Web Service when testing for its performance is that the testing can take place at the level of a single method. Some methods are based on the business logic layer while others directly hit the database. Over the years of performance testing we have discovered, by and large, that database activity dominates application performance.
For database performance, one can test using the CRUD methodology as it is the basis but especially in terms of retrieving data (get function) and updating or adding data (post or put function). Think of it this way, if you knew that hundreds or even thousands of users were attempting to retrieve data, you would want to know where potential bottlenecks may be hiding. Through Web Service, you can discover this because you are able to isolate your search to a single method.
There are two popular applications that take advantage of Web Service performance testing: mainly jMeter and LoadUi. jMeter is the most inclusive of the performance tools. The features are truly extensive. It is compatible with the following features: HTTP, HTTPS, SOAP, REST, FTP, JDBC (database connectivity), LDAP, mail, SMTP, POP3, IMAP, shell scripts, TCP, Java, multithreading, and BeanShell.
LoadUi is a companion of SoapUi. Because it is based on SOAPUI’s Web Services capabilities it allows for testing at the method level and at the scenario level.
Web Service has proven to be a boon not only in terms of an application’s quality but also in terms of its performance. In fact, it has become a standard within the IP industry. If you are building your application on Web Service it allows you to build quality into your product as you create it. In the end, it is a great foundation for both quality and performance.