14 August 2009 - 15:05 Looking at Requirements-Based Testing (RBT): A Newcomer’s Perspective by Crystal Atamian

Coming into this field I had minimal experience in the realm of software testing or QA. So when I heard about this approach to software testing, I couldn’t help but be intrigued. A trained analyst maps out the logic behind the requirements using DTT© and finds the missing gaps and dead ends that typically lead to bugs in production. The technology processes that map, or “model,” to generate test scripts, and viola! – software testing. It made so much sense it was unclear to me why you would do it any other way.

Not many people outside academia tend to concern themselves with the specific details of logical processing. Your average Joe doesn’t think too heavily about deductive and inductive reasoning, or parallel versus sequential processing. The term logic equates for most of us with common sense, so why bother with that level of detail? But when it comes to software testing that level of detail can make a huge difference in terms of both time and money.

When I first began training with Critical Logic, I found that unraveling the logic behind functional requirements was much harder than it seemed. Something that seemed so straightforward involved an inordinate amount of questioning of basic assumptions and details. The level of detail required to create a model, to develop the necessary if-then statements, and to decide if these operations are happening in sequence or in parallel was mind-boggling even for a simple GUI screen. Initially, the advantage seemed to be that the graphing or modeling process broke things down visually so that the user could see the intricacies of the process. Instead of thinking through everything that could go wrong with the given piece of software, DTT© allowed the user to explore the system and question the logical possibilities of each function or field. Breaking down the logic behind software requirements is not an easy task, but once it’s done DTT© can provide an amazing number of benefits to both testers and designers. The irony of all this, of course, is that many months into it this has become second-nature to me, and I now find myself thinking of the process as common sense – given the benefits of modeling as a tool for functional software analysis, why would you do it any other way?

In addition to modeling, the Requirements-based Testing (RBT) approach has exposed me to the world of ambiguity review. Ambiguity review is at the core of Critical Logic’s approach, and stands as one of the most valuable tools offered by the company. Ideally, ambiguity identification proceeds in two steps. The first portion of the ambiguity review is done by someone who is not a subject matter expert (SME).The focus is on ambiguities in the logic and structure of the wording, unclear references and potential missing details. However, since the initial reviewer is not a SME he or she cannot read the requirements for facts that are not explicitly there. Thus, the second stage of the process is conducted by subject matter experts to ensure that the document is complete and correct in terms of the application. Often, in my experience, this is a fluid process where SMEs and Critical Logic staff exchange information, shifting between the first and second stage of this process numerous times. The key element of this process is eliminating problems in the beginning when they are easy and inexpensive to fix. Having one set of specifications and requirements that are clear, determinate, and specific is an asset for developers, testers, and business analysts.

Finding ambiguities is a skill that involves learning how to ask the right questions. Although it is not an automated technology process like DTT©, ambiguity review is easily the most important step in paving the way for DTT’s© effectiveness. In my limited time I have seen first-hand how poorly written requirements can ruin a project. Editing and revision early in the developmental phase is the key to eliminating inefficiencies later in the test cycle.

It is exciting to be part of a company that has the potential to improve existing quality and testing processes to such a startling degree.