« Table of Contents »
Previous « What Are Behaviour Specifications?
The Behaviour Specification Handbook
Behaviour Specifications
No Other Test Cases Are Necessary!
Within a software development team, no test cases other than those represented by the Behaviour Specifications are necessary.
Behaviour Specifications Are Comprehensive
Behaviour Specifications literally are the functional specifications of software components. The specifications for a given software component should be comprehensive and unambiguous. If that is not the case, then team members including developers and testers will not know about all the functionality they are supposed to deliver, and the solution delivery will fail.
No other test cases are required! The logic of this statement is simple — since program specifications need to be comprehensive, then no other tests are needed as all possible test cases already should be covered by the specifications.
The fact that Behaviour Specifications are comprehensive and precise is good news for those businesses interested in having their developers coding in distributed and remote teams.
About Test Independence
With this statement about no other test cases being necessary, I am referring specifically to and recommending a software development team structure and operating model where there are business analysts, developers and test analysts closely collaborating. The goals of the development team are to achieve a cost-effective, streamlined, successful delivery of a solution with an agreed level of quality assurance.
Due to the close collaboration of the team members and common desire to prevent unnecessary duplication of testing effort, the test analysts are operating within the same team and cannot, as described by the International Software Testing Qualifications Board (ISTQB), provide a high-level of test independence. Depending on how the team operates however, there certainly could be a medium-level of test independence. For many clients, projects and solutions, this approach is both efficient and sufficient, and it is specifically within this operating context that I state no other test cases are necessary.
For life-critical systems and solutions however, more rigour is required and there should be a high-level of testing independence. In that case, a separate, independent team or company would perform testing in addition to that performed by the software development team. The additional testing certainly overlaps and duplicates significant amounts of the testing effort performed by the development team. It also requires a lot more time, resources and cost. This additional testing however, is performed outside of the software development team, outside the practice of BDD, and is thus outside the scope of this handbook and the presented recommendations.
Likewise, any other phase of testing that is not performed by the software development team is excluded from the statement of no other test cases being necessary. For example, User Acceptance Testing (UAT) is excluded since it is performed by the business and not by the software development team.
Change Will Happen
As the team progresses through the analysis, development and testing phases, new information may emerge and deeper levels of understanding are reached. This is a natural part of the process and it cannot be avoided. A developer might be in the depths of coding part of the solution and see a situation that has not been specified yet. Alternatively, a business analyst may have a random water cooler discussion and find out more complicated business logic that needs to be accounted for. However it happens, someone will think of another requirement, feature, behaviour, scenario or test case that they believe should be specified. When that happens, carefully discern the situation and ensure that it is not covered already by an existing Behaviour Specification. If necessary, add more Behaviour Specifications or tweak existing behaviours where appropriate.
For continuous improvement purposes, it can be useful to maintain a “beginner’s mind” and try to learn and understand why a behaviour was not identified initially in the Behaviour Specification writing meeting. Keep in mind though that in many cases, timing is everything and there may not be anything that could have been done better.