- Have all the requirements been implemented?
- Have tests been created to verify each of the requirements?
- Have all the requirements been tested for this build/release?
- Which areas of the system are stable and which are not?
Unless requirements can be traced accurately through the related project artifacts, such as business requirements, use cases, functional requirements, design specifications, code, test results, and defects, it is impossible to ensure that the system is being built for the intended purposes and tested adequately -- keeping the project on track and avoiding expensive rework later.
Of course, most projects will have some requirements information in some form -- whether it is formal specifications, wireframes, mock-ups, prototypes, dialog maps, content sheets, previous system releases, user manuals, or even stored in the minds of subject matter experts (SMEs). And it is very likely that the customer has contributed to the requirements by describing what they want from the system in terms of their business needs.
But the upfront time that it takes to document formal requirements properly and completely is often perceived as a barrier to avoid, even though it is easy to recognize that the proven savings downstream more than return the investment. In the rushed atmosphere of "We need to start coding and we need to start now", it is hard to convince anyone to take the time to perform "understood" formal documentation activities, let alone develop and apply a new documentation technique.
Balancing the need for fast development with requirements documentation
A balanced approach that maximizes the contribution of the organization's available resources within the project constraints is required. When you have minimal or out-of-date requirements, a first step in accelerating the capture of a useful understanding of the system and filling in the gaps regarding its purpose and functions is to think in pictures -- pictures that will form a basis for analysis and testing.
With this proven light-weight solution tailored to your timeframes and resource realities, testing is able to capture critical requirements information about the system without slowing development. The resulting artifacts can also serve as a direct input into testing activities, avoiding significant duplication of effort and possible confusions.
Flowcharts and state diagrams provide similar and, at times, complementary methods for visualizing, or picturing, the behavior and functionality of a system, establishing path coverage, and generating ideas for error path or negative testing. Through the rapid process of creating these diagrams and subsequently reviewing and clarifying them and their stories with stakeholders, test ideas will easily come to the fore for later execution.
Narrative user scenarios can be used to complement and expand upon what is provided in the diagrammatic representation. Adding checklists and matrices will further enable testing to be able to rapidly document the functionality to be tested and to be able to measure or assess the progress of that testing easily.
Using diagrams such as these can be very effective to visualize the system, not only for the tester but for the whole project team, and as long as you can capture the information you need to generate comprehensive, traceable test ideas, it doesn't matter what notation you use.
About the author: Trevor Atkins is principal consultant with Silverpath Technologies. Most recently he was a regional director of quality services with UST Global, and before that he was a founder and the vice president of operations of QA Labs, the largest independent software testing company in Canada.