PRODUCT HISTORY
PRODUCT OVERVIEW
BENDER RBT (PREVIOUSLY SOFT/TEST/CALIBER RBT)
QUICK DESIGN
INTEGRATIONS
WHAT'S
NEW IN RELEASE 7
The earliest version of automation support for the RBT process goes back to 1970 in IBM. William Elmendorf of the Poughkeepsie Labs developed a system called Teldap (Test Library Design Automation Program). It was written in APL and brought the largest mainframes IBM had to their knees. Mr. Elmendorf is one of the short list of fathers of black box testing. He is the initial developer of equivalence class testing with boundary analysis.
In 1980 one of my clients, Bank of America, created another mainframe version called CEGAR (Cause Effect Graphing Analysis Routine). Hitachi in Japan, another of my clients, also created yet another proprietary version in 1981.
By 1987 PC technology made it economically viable to create a desk top version. William Elmendorf left IBM and joined in partnership with Bender & Associates to create a whole new incarnation, initially called SoftTest. By 1991 Mr. Elmendorf decided to retire. Bender & Associates became the sole owner of SoftTest.
Over the next eight years major enhancements were added to the processing engine as compute power improved (this is a very compute bound problem). Numerous exports were added to most of the major play back tools.
In 1999 Bender & Associates was acquired by Technology Builders Inc. At that time the product was renamed CaliberRBT to team it up with TBI's requirements management tool CaliberRM.
TBI was acquired by StarBase and StarBase was in turn acquired by Borland. Richard Bender then bought back the rights to RBT. The product was then renamed BenderRBT to avoid confusion with the CaliberRM product which most people just call Caliber for short. Sorry for all the confusion about the name of the product but that's how we got here.
BenderRBT addresses defining
the test completion criteria, designing functional tests to meet the necessary
criteria, verifying the test coverage, and assists in verifying test results
and in maintaining the test library.
CHOICE OF TWO TEST DESIGN METHODS
BenderRBT comes with two distinct test case design engines. When you invoke RBT directly you will be given a choice of which you would like to use.
Cause-Effect Graphing (C-E Graphing) takes you to the Graphing based test engine. Quick Design (QD) takes you to the Pairs-Wise based test engines. This includes Orthogonal Pairs and Optimized Pairs. C-E Graphing is intended for business critical, mission critical, and/or safety critical functions. It ensures that you not only got the right answer, but that you got the right answer for the right reason. It addresses the fact that multiple defects can sometimes cancel each other out. C-E Graphing ensures that defects are propagated to an observable point where testers can see the problem. QD is aimed at testing user interfaces (e.g., web pages, screens in client server applications. It is also applicable in designing configuration tests and quick shake-downs of even critical functions. Both C-E Graphing and QD address reducing the nearly infinite number of potential tests down to small, highly optimize test libraries. They both have full constraint rules support (One and Only One, Exclusive, Inclusive, Requires, and Masks) to ensure that the tests created are physically possible while still supporting full negative testing.
GO
TO Cause-Effect Graphing Overview
GO TO Quick Design Overview
BENDER RBT (PREVIOUSLY SOFT/TEST/CALIBER RBT)
CAUSE-EFFECT GRAPHING OVERVIEW
BenderRBT's Graphic Front-End
The graphic front end to RBT allows project teams to quickly create cause-effect
graphs, complete with node relationships, constraints, and attributes.
When a node is created, users are prompted to enter the required attributes,
reducing the risk of incompletely defined nodes. When the cause-effect
graph is completed, RBT then designs the test cases based on the requirements
depicted in the graph. RBT also uses the cause-effect graph to further
evaluate the requirements for logical consistency. The project team can
use the test cases generated by RBT to review requirements with stakeholders,
or they can use the structured English requirements document automatically
generated by RBT. The more readable the requirements are, the more likely
the project team is to develop the right application.
RBT gives you a number of options in generating test cases.
Test Generation Options
The Run New option will design a new set of tests based on the graph you have just entered.
The Run Old option will evaluate the coverage of a set of existing tests against the current version of the graph.
The Run Both option will evaluate the coverage of a set of existing tests and then supplement these tests to complete the coverage of the graph.
The Revise Desc[riptions] option allows you to modify the True or False definition of a node without having to rerun the graph. It just updates the data base with the new description. This is immediately reflected on all of the generated reports (e.g. Batch Test Cases). This is very convenient in cases where you have a long running graph and find that you want to tune the wording on a description. For example, you may have misspelled something or you want to bring the wording to be more in sync with other sets of tests.
Note: This feature can be used to factor in test cases that were not designed by RBT. There is a dialog for allowing the user to tell RBT about existing test cases, regardless of their source.
To design test cases RBT first generates the list of Functional Variations. These are the primitive combinations of data that must be tested.
BenderRBT's Functional Variation Report
Errors in the requirements logical
consistency will show up in this report.
The Variations are then packaged into highly readable test scripts. The
scripts can then be reviewed by the subject matter experts to aid in validating
that the requirements are correct. In effect, this moves customer acceptance
testing up before coding starts.
BenderRBT's Script Test Definitions Report details every step of the test cases designed, including the input conditions and the expected results (or effects) of each step.
RBT's highly optimized test design algorithms ensure that you get the
maximum coverage for the minimum number of tests.
RBT also generates a number of other views of the test information. The
first is the Test Definition Matrix. This is a compact view of the test
cases. It can be exported as a comma delimited file and imported into
Excel or into "home grown" test tools".
BenderRBT's Definition Matrix uses a table format to display the state of each node in each test case, allowing at-a-glance understanding of each test case.
Another view is the Functional
Variation Matrix. This matrix identifies which variations are in which
test cases.
BenderRBT's Functional Coverage Matrix identifies which functional variations are in which test cases. An "X" means that the variation is in two or more tests. A "#" means the variation is only in one test.
The Functional Coverage Utility uses the Functional Coverage Matrix to
calculate the status of testing. This allows the team and Management to
make intelligent decisions on whether or not to release the application
into production based on quantitative test status.
BenderRBT's Coverage Analysis Matrix allows the project team to quantifiably determine the status of testing. When one or more test cases are selected, the Coverage Analysis function calculates the selected test cases' percentage of weak and strong functiona
l coverage.
Fewer Tests Dialog
This feature allows you to enter in a number less than or equal to the number of total tests and have RBT determine which is the optimal subset of tests - i.e. which tests would give you the greatest possible coverage.
Quick Design - Orthogonal Pairs / Optimized Pairs Based Test Design Engine
Quick Design allows you to design tests in just minutes. You just identify
each test input Variable.
Defining a Variable in Quick
Design
For each Variable you define the States you want to test.
Defining a State in Quick Design
QD concatenates the Variable description with the State description in the generated test scripts. This saves typing and ensures consistent wording of test scripts. In the above example the final description would read "The customer is a Corporate customer".
If needed, you then apply constraints across the Variables/States which
identify combinations of data which are physically impossible at this
point in the system. However, you still want to do full negative testing.
Defining a Constraint in Quick Design
In this example the constraint
rule is that only corporate customers may have building loans. Other functions
prior to this one would have rejected any attempt by retail customers
or government customers from getting this type of loan. The production
data base would not contain any building loans for any customer other
than corporate customers. Therefore, we do not want to generate any tests
at this point contrary to this rule. Note, however, that in testing the
predecessor functions you should have tried creating a building loan for
the other customer types. The test result should have been that the loan
application was rejected.
Quick Design then generates all possible pairs across the Variables/States. This is documented in the Pairs Report.
Quick Design Pairs Report
Note that two of the pairs have a yellow "I" next to them. These are the infeasible pairs - i.e. they violated the constraint we set up.
Quick Design then merges the pairs into tests, again ensuring that no
constraints are violated. You have two choices in generating tests: Orthogonal
Pairs or Optimized Pairs. In Orthogonal Pairs testing each pair occurs
the same number of times across the set of test cases. In Optimized Pairs
each pair is in at least one test. The goal is to do this in the fewest
number of tests possible. We generally recommend orthogonal pairs for
configuration testing and optimized pairs for function testing.
Quick Design Test Scripts Report
In designing test cases, Quick Design
gives you the same options as in the graphing component to create new
tests, evaluate old tests, supplement existing tests, and revise test
descriptions. Again, the existing tests need not have been created by
RBT.
As in RBT, you get the coverage
report.
Quick Design Pair Coverage Report
Optimized Tests
As in the Cause-Effect Graphing
component there is a feature to measure test coverage and identify an
optimal subset of tests.
You also get the Test Definition Matrix.
Quick Design Test Definition Matrix
Minimum System Requirements
Windows NT, 2000, or XP
128 Mb RAM
30 Mb hard disk space for the programs, documentation, and examples
Free disk space for work files (amount of free space required will vary
by organizational needs)
BenderRBT can export the tests it has created to Mercury's Test Director. It populates the test planning section.
Similarly there is an export to Sirius-SQA's TestExplorer test manager.
The tests can also be exported to a variety of playback tools such as Rational's Robot and Segue's Silk.
There is also a link to CaliberRM, Borland's requirements management tool.
Cause-Effect Graphing Test Case Design Component
" New Graphic Front End - The Visio based front end has been replaced with an integrated visual basic C-E Graph drawing tool.
" Existing Test Support - The user now has the option to design new tests, evaluate existing tests, supplement existing tests, or revise the descriptions in existing tests. The existing tests do not have to have been designed by RBT to use this feature.
" Test Optimization - The user can ask RBT to select the subset of tests with the maximum coverage. This is very useful if there is not time to build and run all of the tests before a critical checkpoint.
" Export to TestExplorer - An export to Sirius-SQA's TestExplorer test management tool has been added. It works similarly to the export to Mercury's TestDirector.
" New Cause-Effect Graphing User Guide - The User Guide has been totally rewritten.
" New Help Support - The embedded Help has been totally redone and includes context sensitive Help.
Quick Design Component
" Existing Test Support - The user now has the option to design new tests, evaluate existing tests, supplement existing tests, or revise the descriptions in existing tests. The existing tests do not have to have been designed by RBT to use this feature.
" Test Coverage Analysis - Quick Design can now calculate the functional coverage status based on which tests passed/failed in execution.
" Test Optimization - The user can ask Quick Design to select the subset of tests with the maximum coverage. This is very useful if there is not time to build and run all of the tests before a critical checkpoint.
" Export to TestExplorer - An export to Sirius-SQA's TestExplorer test management tool has been added. It works similarly to the export to Mercury's TestDirector.
" New Statistics Report - A Statistics Report similar to that in the Cause-Effect Graphing component has been added.
" Strong Editing Support - When you edit your input data Quick Design automatically ensures that other portions stay in sync. For example, if you delete a variable Quick Design will automatically adjust any constraints which included that variable. There is also strong "undo/redo" support.
" New Quick Design User Manual - The Quick Design User Manual has been fully updated to reflect the changes.
" New Help Support - The embedded Help has been updated, including the context sensitive Help.
The following materials present more detail about the BenderRBT tool:
BenderRBT-V7-0-Data-Sheet
(PDF file, 420K)
BenderRBT-Tool-Benefits (PDF file,
111K)
BenderRBT-Integration With Mercury (PDF file, 320K)
BenderRBT-Integration
With TestExplorer (PDF file, 225K)
BenderRBT-Cause-Effect
Graphing User Guide (PDF file, 1,299K)
BenderRBT-Quick-Design-User-Manual
(PDF file, 727K)
BenderRBT Release
7 - What's New (PDF file, 82K)
HOME/ RETURN TO MENU SELECTION