In the fast-paced changing world of software product development there is a continuous challenge to document the expectations for the system and its internally and externally facing behaviours. Requirements often suffer because of the challenges of keeping up with an iterative project life-cycle, evolving product scope, and uncertain or changing GUI/Screens.
However, the need remains for all stakeholders to optimize agreement, minimize risk, and minimize rework costs. From a tester’s point of view this translates in part into how test coverage of the system can be assured and made visible to all the stakeholders?
In “Testing Without Requirements“, we suggested using checklists, matrices, and user scenarios as ways to approach testing when requirements are non-existent, not complete, or not ready at the time testing needs to start.
Even when you have minimal or out-of-date requirements, you can use different methods to help you rapidly define the application, describe its functions and derive an efficient plan to drive your testing effort.
A first step in developing these tools is to think in pictures.
“Imagery is the most fundamental language we have. Everything you do the mind processes through images,” says Dennis Gersten, M.D., a San Diego psychiatrist and publisher of Atlantis, a bi-monthly imagery newsletter.
Benefits of creating User Scenarios / Use Cases:
- Easy for the owner of the functionality to tell/draw the story about how it is supposed to work.
- System entities and user types are identified.
- Allows for easy review and ability to fill in the gaps or update as things change.
- Provides early ‘testing’ or validation of architecture, design, and working demos.
- Provides systematic step-by-step description of the systems’ services.
- Easy to expand the steps into individual test cases as time permits.
User scenarios quickly provide a clearer picture of what the customer is expecting the product to accomplish. Employing these user scenarios can reduce ambiguity and vagueness in the development process and can, in turn, be used to create very specific test cases to validate the functionality, boundaries, and error handling of a program.
And, every picture tells a story and stories or scenarios form a basis for testing. Using diagrams can be very effective to visualize the software, not only for the tester but for the whole project team.
Creating user scenarios/use cases can be kick-started by simply drawing a flowchart of the basic and alternate flows through the system. This exercise rapidly identifies the areas for testing including outstanding questions or design issues before you start.
In her article “A Picture’s Worth a Thousand Words”, Elizabeth Hendrickson notes, “Pictures can pack a great deal of information into a small space. They help us to see connections that mere words cannot.”
The Unified Modeling Language (UML), which is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems can be employed to help provide these pictures. However, there are many less formal types of notations you can use to put together different simple diagrams, such as activity flow charts, data flow diagrams, state diagrams, and sequence diagrams that can be just as useful for meeting your project needs.
As long as you can achieve the goal to obtain enough information to help you with the task of generating comprehensive test cases ideas, it doesn’t matter what notation you use. Start with a basic diagram, depicting the main modules of the system and when, why, and how they interact; from there, you can create more detailed diagrams for each module.
What should be in the initial picture? The very basic information you have. Is it a client-server application? Is it web-based? Is there a database? What are the major tasks the system is supposed to perform?
You have to focus on how the system behaves. End users can help define user scenarios (or use cases) in a diagram format, providing details of the system that will help you not only understand what the client is expecting but also will allow you to validate the diagrams previously drawn.
Describing the tasks and subtasks in detail will provide test scenarios and analyzing the relationships among the modules will help determine the important inputs for the overall testing strategy.
Flow Charts
A flow chart is commonly seen as a pictorial representation describing a process, defining the logical steps including decision points and activities. Flow charts are useful for defining the paths you want to verify or to force into an error condition.
Flow charts can take different forms, such as top-down flow chart, detailed flow chart, workflow diagrams, and deployment diagrams. Each of the different types of flow charts provides a different view or aspect to a process or task. Flow charts provide an excellent form of documentation for a process, and quite often are useful when examining how various steps in a process work together.
State Diagrams
Another option to capture the software behaviour is the use of state diagrams. State diagrams are used to describe the behaviour of a system. State diagrams describe all of the possible states of an object as events occur and the conditions for transition between those states. The basic elements of a state diagram are rounded boxes representing the state of the object and arrows indicating the transition to the next state. The activity section of the state symbol depicts what activities the object will be doing while it is in that state.
All state diagrams begin with an initial state of the object. This is the state of the object when it is created. After the initial state the object begins changing states. Transition conditions based on the activities determine the next state of the object.
Summary
Flowcharts and state diagrams provide similar and at times complementary methods for visualizing, or picturing, the core information to be captured in a user scenario or use case. Throughout the process of creating these diagrams, test case ideas will come to the fore to be rapidly captured for later detailing.
Time well-spent to better understand the software to be implemented and tested not only improves your actual testing activities, but also helps improve the organization’s understanding of the product, and thereby can significantly improve the product as a whole.
