Testing, Testing, 1, 2, 3…

A use case describes a system’s behavior as it positively or negatively responds to a request from a stakeholder under various conditions. Thus, use cases provide a convenient user/functional test description for the system under definition. I find most Quality Assurance groups would rather work with use cases versus requirement statements when generating test cases. As organizations mature into a Quality Center of Excellence, it decreases a tester’s ability to know the systems under test in any detail because they are tasked out to test just about everything in that organization. Also for these QA groups, it is usually the first time they have been given the requirements to base their test cases.

Use cases are something very easy to work with to generate those test cases because use cases already contain the basic and alternate flows of the software behavior. Therefore it makes it easier for a tester to know the positive or negative tests that need to be created. Test generation becomes difficult if the tester has only requirements statements to work from because certain behavior descriptions may be missing. As a result, the tester usually ends up guessing all the ways a piece of functionality needs to be tested or has to re-interview the stakeholders to ensure everything is being tested. Therefore, if the various behaviors of the software are not detailed in use cases, then the testers will have a difficult time discerning the right behavior from a defect. I have found in some organizations that the testers work with the business analysts to help write the use cases. QA folks will need to write test cases at some point in the software development life cycle (SDLC), so why not include them from the beginning by getting their help in writing the use cases which will later evolve into test scenarios and test cases.

On many projects, testing is later in the SDLC. Requirements defects remain in the software until they are discovered in the testing phase. At User Acceptance Testing (and production), significant dollars are required to fix requirement errors after the development teams have already built functionalities based on those requirements. We have all read studies that have shown the cost can be up to 100 times more to fix a requirement defect found by an end user than to fix that same defect found during requirements definition. In our experiences, we have seen an error found during requirements development can take only minutes to fix, versus that same defect found at UAT takes hours or days to fix. We all know any action we can take to find defects in requirements definition will absolutely save us time and money.

If you start generating test cases earlier in the SDLC, you’ll detect requirements defects shortly after they are made. This stops these defects from filtering into the rest of the SDLC and cuts your testing and maintenance costs. So as soon as use cases(s) are approved by the stakeholders, the test team can divide each use case into numbered tests and write an execution plan. In addition, they can create all the data needed to test the different data permutation. The main basic flow test case should come first because you always want to test how the software behaves in a high volume scenario. It should be created before all of the alternate flow test cases. On a side note, the main basic flow lends itself very well to performance/load testing because it is a high volume scenario.

Thanks goodness for modern technology. Today, there are software products out there that allow analysts, stakeholders, testers, and developers to visually walk through use cases together, thus allowing them to share a clear vision of how the software will behave. By visually tracing the basic and alternate paths for each use case, you can find incorrect, missing, or unnecessary requirements, which can be fixed long before any code is written. After the use cases have been approved by all parties, the requirements center can automatically produce test scenarios. These test scenarios are created from the use cases and have traceability to the functional and user requirements of the software. The QA team can take these auto generated test scenarios and modify them to create test cases. The test cases a are detailed set of tests with specific test data used by a tester to record the expected results. This technique of visualization controls a project’s cost and schedule by finding requirement errors very early in the SDLC.

Don’t forget to leave your comments below

---

Zeena Kabir is a Sales Engineering Consultant for Blueprint Software, the leader in requirements definition and visualization software. Prior to Blueprint, Zeena has worked 20+ years in the IT field in the areas of requirements engineering, testing, and development. She holds a Bachelor of Science degree in Computer Science and a Master of Science degree in Software Engineering from the University of Maryland. She resides and works with many IT organizations in the Mid-Atlantic region.