12 June 2009 - 12:40 Exploratory Modeling by Mark Lathrop, Lead QA Analyst

As an independent consulting and testing organization, the point at which we are brought into the fold of a project varies greatly. There are times when the project is past the point at which debugging the “spec,” one of the main value-drivers we offer, is going to be a viable activity. Often in these cases the stakeholders are already working with developers and a prototype of the application to be delivered, COTS (commercial-off-the-shelf) or homegrown. Although not optimal, we can use our graphical modeling technology to leverage the work that has already been completed, as well as ensure decent test coverage and documentation.

One of the ways we can accomplish this is through a modified exploratory testing technique, sometimes called “exploratory modeling.” Even exploratory modeling needs a plan. We’ve used many ways to break up applications into “chunks” for test planning, but in the case of a prototype we usually start with a screen inventory. We can put together this screen inventory ourselves (yes, by “exploring” the application) and learn about how the application works in the process. Based on past experience and the amount of features found, we can usually put together a good estimate of how long it will take to model each area of the application as well.

Now to the part where having good technology at hand really makes a difference when practicing an exploratory testing technique. Our modeling technology, DTT©, is very apt at allowing the tester to model the functionality of an already-existing prototype. The logical possibilities of each function or field can be captured in the graphical model, although what is captured is still at the discretion of the tester exploring the application. Sometimes the parameters of this discretion are a predefined scope decision by the QA manager or our client. Other times it is simply a limit on time or budget. Either way, the functionality is captured in the model, and DTT© can generate a repeatable script of what was explored and exercised. Even if never exercised again, this documentation is valuable if it is needed for regulatory or change-management purposes, or, more likely, for the basis of a future automation effort. Like any other technique we use, bugs have to be tracked and stomped if found.

At the end of the day, exploratory testing is really reverse engineering of the application (exploratory) and then deciding if you like what you see (testing). Exploratory testing is the test engineer’s last resort for poor specification of expected software behavior. What the model facilitates is the capturing of the lost functionality so that we can migrate from discovery to formal testing of the application, all in one step. Also, the model lets us generate a functional spec so that the next test engineer does not have to re-explore the same application, and knows what has already been covered.

Using the above technique allows Critical Logic to continue delivering value at all stages of the test cycle. To learn more about the DTT© modeling technology discussed here and our other capabilities, contact us at www.critical-logic.com/contact.php.