24 September 2009 - 14:40 Your True/False Statement: True or False? By Mark Lathrop, Lead QA Analyst

One of the most important outcomes of an ambiguity resolution process is the accurate definition of logical comparisons in specifications. A completely defined logical comparison allows for more effective test design and ensures that the software under test is functioning as required by exercising its boundary A quick example of the importance of properly defining logical comparisons in specifications can be shown with requirements involving the use of dates for filtering records. Here is an example requirement:

REQ A: Records entered after January 1st, 2000, will be converted to the new format.

Sounds straightforward, right? In this requirement the boundary for records being converted or not converted lies between January 1st and January 2nd. Those are the only dates that we need to test to verify the functionality of the software. January 1st’s record is not converted; January 2nd’s record is converted. There is no need to test December 31st or January 3rd to see what happens. When I see a requirement like this, I will often log an ambiguity to clarify the boundary. Does the business truly want the boundary between the 1st or 2nd, or is the business intending the boundary to be between the years 1999 and 2000? Just to see the difference, here is the same requirement with that boundary:

REQ A: Records entered January 1st, 2000, or later will be converted to the new format.

There is not much of a difference in wording here, and when the requirements are being written by business experts and not software engineers, these issues can easily slip into a specification.

Another boundary issue I have seen in specifications of logical comparisons concerns dollar values. Recently, I reviewed a document with a cost limit for processing an order without manager approval. The requirement read something like this:

REQ B: Orders over $100 must be routed to the manager for approval.

Does it sound straightforward again? Not really. This requirement should always result in an ambiguity question being asked. One problem with defining the intended boundaries of the logical comparison here is the currency format being used by the system. Is the logical comparison really between $100 and $101, or actually $100.00 and $100.01? Most likely, the ambiguity question would reveal that orders equal to $100 would need approval as well. In that case the requirement would have to be rewritten; given here using the decimal:

REQ B: Orders equal to or over $100.00 must be routed to the manager for approval.

This requirement implies a testing boundary of $99.99, no approval required; $100.00, approval required.

Although the examples given here concern minor differences, eventually comparison boundaries that are misunderstood by a programmer will have a serious enough impact to the business as to require the additional cost of rework. At Critical Logic our Right From The Start™ process aims to eliminate that possibility. We’ve had a great amount of success in the past reducing the amount of rework required in application development through our process, rework which is often 50%-75% of a project’s entire budget. This not only reduces the overall cost of the project, but also the time-to-market of the application being developed.

If you would like to know more about what we do and conduct a free needs assessment for your organization, contact us today.