The following materials may be downloaded, copied, and distributed as you see fit. However, you must retain the Bender RBT Inc. copyright notice on it or materials derived from it. If you have any questions or comments about any of the papers just contact us at
The Bender-Ambiguity Review White Paper gives an overview of the process. It also provides a master checklist of ambiguities to look for.
(PDF file, 63K)
The Bender-Applying Ambiguity Reviews Late In Development describes how to apply the process even though coding may already be well underway when you start.
PDF file, 72KB
The Bender-Business Case For Software Quality contains statistics on over a dozen areas that can be affected by poor quality software. These include the cost of defects in production, the litigation exposure, support costs, etc.
(PDF file of a Power Point presentation, 975K)
The Bender-How Do You Know When You Are Done Testing presents quantitative completion criteria for both black box (i.e., requirements based) and white box (i.e., code based) testing.
(PDF file, 192K)
The Bender-Requirements Based Testing Process Overview presents the steps in the RBT process and how they fit into the rest of the development life cycle.
(PDF file, 247K)
The Bender-SEI-CMM Proposed Software Evaluation and Test KPA is a supplemental KPA for the CMM. This was developed in conjunction with a number of our customers and reviewed / enhanced by numbers of industry testing experts. This was created because it was felt that the CMM is fairly weak in this area. The CMM-I, however, has addressed this topic in a more robust manner.
(PDF file, 237K)
The Bender-Testing Software Rewrites addresses an approach to ensuring the quality of the riskiest of software projects: the replacement of a major existing system(s) with a new, re-engineered implementation. The failure rate for such projects is at least sixty percent. Even when the new system makes it into production, quality problems can cause disruptions for years. The issue is how to ensure functional compatibility in those areas where the applications rules must be consistent from the old system to the new one.
Bender-Testing Software Rewrites
The Bender-SDLC paper presents the objectives and requirements for a full software development life cycle. This was originally developed for a number of projects in which we assisted clients in creating their own project life cycles. We have since found it useful in evaluating our clients' project life cycles to aid in identifying areas of weakness which may impact the project's schedule, budget, and quality.
(PDF file, 320K)
The Bender-WTR Templates are the templates from our Writing Testable Requirements course. It contains the detailed definition of the Objectives ument and the External Specification (i.e., Requirements Specification). This includes the detailed list of properties from Data Stores, Data Flows, Use-Cases, Functions, and External Entities / Actors. Some of this material might not make sense unless you have taken the WTR course.
The goal of an effective set of tests is to ensure that if there are any defects in the product one or more of the tests will visibly fail. However, when a test is run it usually causes the execution of many, many steps in the code, most of which are not observable. So the tester is deducing that all of those intermediate steps worked correctly by looking at the end results. The reality is that defects might cancel each out and you get the right answer for the wrong reason. Therefore, the test design process must ensure that defects are propagated to an observable point.
Bender-Designing Tests That Ensure The Observability of Defects
There are three basic approaches to designing tests from requirements. These are path sensitizing as implemented in the BenderRBT test design tool, path analyzers which essentially design tests to cover each decision and step in the rules, and combinatorics approaches such pair-wise testing. This paper compares the effectiveness and efficiency of the various approaches.
Bender-Comparing Requirements Based Testing Approaches
The Bender-RBT Estimating Guidelines contains the guidelines we use in estimating the RBT testing effort.
Bender-RBT Estimating Guidelines
William Elmendorf is one of the fathers of disciplined and rigorous approaches to software testing. He passed away in August 2006. William-Elmendorf-In Memoriam presents a summary of his long career and the contributions he made to our industry. (PDF, 122K) In Evaluation of the Functional Testing of Control Programs - 1967 he describes equivalence testing for the first time, along with numerous other key breakthrough concepts. (PDF, 1,272K) In Automated Design of Program Test Libraries - 1970 Bill creates the first model based and rigorous approach to software testing called Cause-Effect Graphing.
William-Elmendorf-In Memoriam (PDF, 122K)
Evaluation of the Functional Testing of Control Programs (PDF, 1,272K)
Automated Design of Program Test Libraries (PDF, 2,171K)
HOME/ RETURN TO MENU SELECTION