A Tester s Perspective: Musings on the Big Black Box


A Tester's Perspective: Musings on the Big Black Box

graphics/box_icon.gif graphics/thinkingbox_icon.gif

Let's consider for a moment the perspective of the testing team in a traditional, non- use-case-driven development process. In most situations, the test team enters the development process relatively late in the game. Perhaps the testers have been provided with at least a minimal set of specifications, perhaps not; but in either case they will most likely approach the system to be tested as an unknown, a "black box" that needs to be tested . While reasoning about the task, each tester may ask the following questions.

  • "What, exactly, is this system supposed to do, and in what order is it supposed to do it?"

  • "What are all the things that can go wrong with the system, and how is the system supposed to behave when this happens?"

  • "How can I create and record a set of testing scenarios in which I can put this system through its paces?"

  • "How will I know when I've tested the system completely and thoroughly?"

  • "Is there anything else this system is supposed to do, or not do, that I need to know about?"

And perhaps the last, even more telling question:

  • "Given that the system is coming out of development late, and given that the shipment date has not been moved, is there any way the testing team can start earlier on the next project and avoid this inefficient 'late discovery' process?"

Now let's consider the perspective of a testing team in an organization that has successfully adopted the use-case technique for expressing the majority of the functional requirements of the system. In this case, in addition to the black box itself, the team members will discover the following assets:

  • graphics/suppspec_icon.gif A comprehensive set of use cases that documents an ordered sequence of events describing how the system interacts with the user and how it delivers its results to that user

  • A use-case model that documents all the use cases for the system, as well as how they interact and what actors drive them

  • Within each use case, both a basic flow of events (the main or "happy day" path through the system) and a series of alternate flows that defines what the system does in various "what if " scenarios

  • Descriptions of pre-conditions (system states that must be true before the use cases executes) and post-conditions (system states that must persist after the use case has executed)

  • A supplementary specification that defines the nonfunctional requirements of the system, including the usability, reliability, performance, and supportability of the system


In this case, the tester's question might well be different: "Have I died and gone to heaven?"

It seems clear from these two scenarios that one of the most significant benefits of the use-case technique has now come to light.

The use-case technique builds a set of assets that can directly drive the testing process.

From the standpoint of developmental efficiency and resultant product quality, it also seems clear that by employing use cases the team can achieve a vastly improved development process over whatever process existed before.


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
Year: 2003
Pages: 257

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net