Imagine writing a single Cyara test case and being able to use it to test any application you wanted. Imagine a single test case that would allow you to start with a test case written for one language and quickly support dozens of languages. All this is possible and more when you understand the concept of a test case built using a wireframe model.
Before we go too far, it is important to make sure we are all speaking the same language.
Test Case: A voice test case is a test script that reflects what the synthetic caller (Cyara) expects to hear, and what replies are needed to navigate a desired path through the IVR application. The two most important parts of a test case are the Expect-to-Hear field and the Reply field. Combining a series of Expect-to-Hear fields with appropriate Reply fields produces smooth navigation from the first prompt to the last.
Test Data: Test data represents the values, words, alphanumeric characters and/or numeric characters that can be substituted within a test case. Building on the earlier example, imagine a list of values in a table that reflected the series of prompts expected to be heard when dialing an IVR application. The first item in the list represents what was expected to be heard as prompt #1. The second item in the list is what was expected to be heard as prompt #2. Continue this substitution process for the balance of the test case and the testing outcome would be the same had the test case contained the same values, but hard coded into the test case. Test Data allows values in a table to be used as substitutes for the values that would normally be typed directly into a test case. Thus, Test Data is a table of values to be substituted into designated locations within a test case.
Wireframe: A Wireframe refers to a unique form of test case in which all content for every step is derived from test data. A Wireframe test case has no static info within the test steps; every element of every step is pulled from a Test Data table and substituted when the test case is executed. Essentially, a Wireframe test case cannot run without being connected to test data, as there is no testable content in the test case without the data from the table.
So how is a Wireframe test case valuable if I need to spend time building a data file? Multilingual apps and flexible campaign test case listings come to mind.
We’ll start by looking at the multilingual use case, like what Vishad Garg from Oracle discusses in his recent Xchange 2020 Virtual Summit presentation. If all the prompts in the test data were in English, translating them to French would produce the same set of functional tests, but in French. The translated prompts would serve as the master list for recording the translated prompts. The existing app would be modified to utilize the new prompts and could be tested with the newly translated French test data. Imagine having all your apps in all your languages using the same prompts. The process to support additional languages would be very straight forward.
So let’s address testing flexibility with Wireframes. Imagine having a single Excel spreadsheet containing all the steps for all the test cases created. Let’s call this your Test Data Master Listing. As each record in the Test Data Master Listing file includes the dialing number and desired ANI/CLI along with the necessary content for all fields in the test case, it is possible to build a campaign consisting of any combination of test cases by simply copying the rows of data from the Test Data Master Listing file to the campaign’s test data file and launching the campaign.
Wireframes allow you to create a system of test case designations by which you could select specific rows from the Test Data Master Listing. The designations could occupy one or more cells in each row of the worksheet. Using Excel’s filtering tools, it would be easy to select the specific test cases that met the testing criteria.
Designations could reflect account types and status, authentication status, external services accessed, routing strategy invoked, call queue invoked, ANI number used and any other data that can vary by test case. Additionally, the wireframe test case can contain placeholders for as many test case steps as you want. Any steps with blank test data fields will be ignored.
Personally, I built a wireframe model with 50 test case steps and a Test Data Master File capable of supporting 50 steps per test case. When I combined the two, I have the capability to run a single campaign using a single wireframe model that supports up to 50 unique test cases, each with a maximum of 50 steps. Need 100 x 100? No problem. Variable numbers of steps per test case? Can do!
While the capabilities of a Wireframe Model and associated Test Data Master Listing are not universally applicable to all testing situations, where it does work it can save a great deal of time and make test automation very easy to accomplish.
In case it would be helpful, I have made a copy of my Wireframe Model and Test Data Master Listing available for Cyara subscribers in this Developer Central article. Head there and you can download the zip file with the content inside.
And, if you have any questions about the topic of wireframe models, feel free to drop me a note. Better yet, respond to this posting and share your thoughts and ideas.
May your testing always yield success.
