The easiest way to talk about Qualitest web testing is to use a real-life example. So today, let’s use an ISBN validator with an interfacing GUI, where we make use of web services as the communication between the two API’s. The ISBN validator will be a public one found online whose functions we cannot alter; the GUI interface that the user interacts with will be one of our own construction. What’s an ISBN, you ask? An ISBN is a unique identifier code possessed by every published book, like a fingerprint. All copies of the same edition of the same book have the same ISBN.
What are the logical input and output fields? Let’s assume that the only way our GUI will allow us to look up a book is by ISBN; however, our GUI will allow for bulk entry of these ISBN codes. And let’s have our GUI to display each book’s title after validating the ISBN, and showing it next to the ISBN. We will request our code without hyphens, but our GUI will be smart enough to strip them out if found. But other than that, let’s make our GUI dumb and let the ISBN API have to deal with all other entry problems. We will treat spaces and commas as separators between separate ISBN’s.
So let’s get back to the expectations of those pesky request and response strings. We need to format our ISBN API requests to be able to get a response, and our GUI needs to know what to expect so it can parse it properly. Logically, the outbound message to the ISBN API will send a text string stripped of hyphens, and make independent calls for each potential ISBN string found (hey, we need to give our GUI some intelligence). Our ISBN validator will work for both 10-digit ISBN’s (which can end in ‘X’ but is otherwise limited to digits) and 13-digit ISBN’s (which is entirely limited to digits).
You will need to play with the ISBN API to determine how it works before the GUI interface API can be completed, so it knows how to behave. What behavior questions do we have? In our next paragraph, let’s deal with ISBN concerns.
If a 10-digit ISBN is invalid, will the ISBN validator a) suggest a one-character correction based on the last character (the checksum) and back-solving b) execute the query using the one-character correction? c) simply respond that the ISBN is invalid without a suggestion? What is the error response for ISBN’s that are neither 10-digit nor 13-digit (and therefore invalid – this check would be easy to program into our GUI)? What is the error response for 10-digit ISBN’s that have valid checksums but don’t exist? What is the error response for 10-digit ISBN’s that have invalid checksums but still don’t exist after doing a one-character correction? What is the error response for 13-digit ISBN’s with an invalid checksum? What is the error response for a 13-digit ISBN that has a valid checksum but does not exist? What is the error response for a 10-digit ISBN that is not [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9X] ? And lastly, what is the error response for a 13-digit ISBN that contains non-numerical characters?
Are you ready for us to build some test cases? I thought you were. We’ll need to build test cases that look at the request strings, the response strings, and the GUI display, to ensure they display what we expect them to. But what else is of concern? We also need to worry about unusual responses in the title field, which we’ll describe in the next paragraph.
Welcome to the next paragraph! Let’s describe some book titles we need to know we can deal with, for valid ISBN’s that return a title. What if the title contains Unicode, which we’ll need to check for a variety of languages? What if the title is really long, like the 231-character title belonging to 0-374-53204-4; will it get truncated? What if the title comes back as blank or NULL, due to some potential mistake at the ISBN API level? Oh, and here’s a weird one: on rare occasions, the same ISBN mistakenly gets attached to more than one book – how do we report the potential for multiple books sharing the same ISBN, like 0-590-76484-5? We’ll need to test this by looking at the response, then adapt our GUI interface accordingly.
Now let’s look at issues with the GUI itself: What happens if we hit a limit of the GUI display size? Do we have a vscrollbar, or a method of paging, or a warning about truncation of the results? If we hit the ISBN API a lot from the same machine, is there a way to ensure that the right web service responses feed back into the GUI, connecting to the right requests, with none getting lost?
I hope this example helps you see the role that web services plays in the API development world, and the challenges they face for proper implementation.