Introduction

• Creating test cases using specification-based testing
• Identifying and creating test cases for program boundaries

Software requirements are undoubtedly the most valuable artifact of software testing. By requirements, I mean any textual document that describes what a functionality should do. Requirements tell us precisely what the software needs to do and what it should not do. They describe the intricacies of the business rules that the software has to implement and we need to validate. Therefore, requirements should be the first artifact you go for when it comes to testing!

We explore specification-based testing. These techniques use the program requirements—such as agile user stories or UML use cases—as testing input. We will discuss how to use all the information available in a requirement to systematically derive a set of tests that exercise that requirement extensively.

Where does specification-based testing fit into the entire testing process? Imagine that a software developer receives a new feature to implement. The developer writes the implementation code, guided by test-driven development (TDD) cycles, and always ensures that the code is testable. With all the classes ready, the developer switches to “testing mode.” It is time to systematically look for bugs. This is where specification testing fits in: it is the first testing technique I recommend using once you’re in testing mode.

As I mentioned, the idea of specification-based testing is to derive tests from the requirements themselves. The specific implementation is less important. Of course, we use source code to test, too—this structural testing is the next technique in the workflow. Once you have a complete picture of all the techniques, you will be able to use them iteratively and go back and forth between them.