This is the story about validating the specification by running the functional testing in SoapUI.
Although the SoapUI does have the functionality of supporting the REST service and therefore testing the REST service project, for this project we decided on a Soap service, due to some security requirements that are easier to implement on a mentioned service.
Margins of the work responsibility for a Business analyst are set mainly depending on an organizational structure and size of a company you work in. But no matter any of the accountable parameters that are setting those margins, from time to time you have to step down below the deck and understand the implementation of business requirements.
This is the story about validating the specification by running the functional testing in SOAP UI.
Although the SoapUI does have the functionality of supporting the REST service and therefore testing the REST service project, for this project we decided on a Soap service, due to some security requirements that are easier to implement on a mentioned service.
After going through business needs and requirements, as an initial document for a Soap service, we created a simple spreadsheet that had a list of methods and their associated triggering descriptions, for each method a list of parameters and for each parameter a list of validations and formatting rules.
Method associated triggers
| Message Delivery |
| Frequency |
Ad-hoc |
| Operation |
POST |
| Message Content |
Web service call |
| Message validation |
Business rule 07 |
| Acknowledgment of receipt |
Status code 200 |
| Failure of receipt |
Error status code/validation NACK message |
Methodparameters
/Running-SOAP-service-tests-from-Excel/Capture.PNG.aspx "Service method parameters")
This was enough to begin coding, for indexing and navigation of the methods in the service we used „Microsoft Compiled HTML Help”, so it was imperative to keep the code neatly documented and organized. Mentioned method of documentation is not without its fuzzy little ways especially when putting an effort in transferring the documentation to another remote team, but it provides a decent and transaparent documentation of the service. Important to note here is that it provides documentation on comments in the code, so in case of any changes comments must be amended or added, luckily Microsoft Compiled HTML Help has a versioning schema. To give you an idea of the size of a service it consisted of 9 methods and each method had a max of 30 parameters.
Now that we have gathered the specification, code and code documentation, all we are missing are tests that validate the code behind. This is where SoapUI comes in to play, since this was my first encounter with this tool it took three full days of exploration, this also included installing a trial of a PRO version with some great features out of which the „Forms“ really sticks out it enables the user to avoid playing with XML structure in the calls and have a preformatted entry for the parameter values.
Although even the free versions of SoapUI is the Swiss-Army knife of automated functional and regression testing with a vast range of functionalities and features covering from security and multi-environment coverage to load testing and reporting. From BA standpoint I need a simple (mother&father of all software) excel table that tells me if requested specifications match the code that is produced and can do that each time we have changes in the code or we make a deployment to next development environment. To do this we used a scripting language based on Java platform with a really neat name „Groovy script“. Although developer that worked on this haven't got any experience with Java he was happy with the internet community support.
The base idea was to create a mechanism that will:
1. Read the excel table where one row would be treated as one call.
2. Set values from columns in the table as a parameter in the call.
3. Read responses of those calls and write them back to the excel table.
4. The last column in excel table created as a validator for those responses.
.png.aspx "Excel-Soap Ui-Groovy script diagram")
So for an attribute like „Customer forename“ with the validation and formatting rule:
„A minimum of 2 to a maximum of 100 character field. This must be restricted to the following characters: blank space, hyphen (-), A-Z. Apostrophe ‘ “
We can create tests that are covering all cases where we are expecting the negative response, and then a line of tests where a positive response is expected. Validator for those calls is created in an excel table(last row of the column) depending on the response code or message in the call response, it will mark the field correct color.
All in all, the system is relatively easy to implement, it does not require much maintenance and works surprisingly fast(our setup) 100 lines of calls are done in 3 sec. But the most significant advantage here is that using excel tables as a primary tool for BA resource puts a straight line in the job description and responsibility between a developer and a B.A resource.
On the Below image, you can see what it takes to manually load and run the test in the SoapUI.
Tags: Analytics, BusinessAnalysis