Site Map | FAQ

Benefits of Test Data Creation and Test Data Design

• Reduce the cost and effort to resolve and reduces the amount of scrap and rework on the project.
• No matter how many testers you have, they all are going to come back with the same test case.
• Provides better wording of the test descriptions than wording in original specifications.
• Allows the test cases to be reviewed by the users/domain experts to validate the system or application rules and find defects in specifications by
  reviewing the test cases.
• Moves a major step of user acceptance earlier in the process before the code is written.
• Address defects that might be hidden because they are not directly observable.
• Increases code coverage, and decreases the likelihood of hidden errors canceling each other out.
• Allows companies to achieve major savings in the effort to script/implement test cases as well as reducing the time to run test cases,
  validate test cases, and maintain the test library.
• With one fourth the tests for equivalent coverage, this results in over a ten X reduction in the cost and effort to build executable scripts.
• Ensures that code coverage is 2 to 3 times better at delivery of the application. Most organizations only achieve 30% to 35%. For
  organizations that must meet test coverage criteria set by various government agencies (e.g. FAA, FDA, DOD).
• Helps ensure the system maintains data and transaction integrity even under adverse conditions.
• Avoids confusion in exactly how to set-up the test and what the results should be. Those not using RBT to design tests often use subtly or even
  significantly different wording to describe the same condition.
• Forces the tester to ask questions of how individual functions work and how those functions should work in relation to other functions.
• Numerous defects are detected which are not normally found until system integration testing.
• Configuration test design
• Ensures elimination of impossible test combinations while still supporting full negative testing.
• Protects the investment in the existing test cases.

• Provides management with quantitative measure of the quality of the application. Go / no go decisions are made on a quantitative basis function by function.
• Allows testers to decide which test to implement first.
• Optimizes test coverage when time is limited.

• Saves redundant data entry because it is described once in RBT and that description is replicated across all the RBT test cases.
• Exported into Mercury Interactive’s Test Director, saving an enormous amount of redundant entry.
• Reduce rework time by ensuring immediate notification of requirement changes, keeping all stakeholders up to date on the project.
• Create self-documenting tests which saves scripting time.
• Allows easy integration with non-standard tools
• Allows flexible integration of test information in other documents

• Saves testers time.
• Produces test definition matrix and test coverage matrix with one mouse click instead of hours spent building an Excel spreadsheet.
• Ensures that the tests are in the format most useful to needs of the project.
• Switching between formats only requires one mouse click. This is especially useful when doing projects for the federal government since they require formats necessitating a lot of work to create and maintain.

• Analyzes how much the existing set of test cases cover the rules of a new or revised function.
• Identifies what additional test cases are now needed, what modifications need to be done to existing test cases, and which test cases are now redundant.
• Allows testers to maintain an optimal test library while minimizing rework of tests already built.
• Ability to prioritize the testing effort By focusing on the tests which give the greatest coverage first, a reasonably stable version of a given component can be created for use in early entry into system level integration test.
• Assist when projects find tight time or resource constraints limit how many tests can be implemented and run.

• Identifies impacted tests when a specification changes.
• The test cases are often more detailed and easier to read than the original specifications. Users use this view to ensure that what is being built matches their expectations.
• Provides mechanism to move user acceptance testing earlier in the life cycle long before code has been written.
• User do not have to be familiar with RBT as they are viewing outputs produced by it.
• Ability for users to make informed decisions as to whether the application is ready to deploy.
• Users do not have to be familiar with RBT as they are viewing outputs produced by it.

• Minimize user ramp-up time by providing quick and comprehensive training.
• Ensure that they are correct, complete, unambiguous, and logically consistent.
• It is a useful skill for users and developers in addition to the testing staff.
• Staff can be trained in less than a day to apply this step.
• Uncovers unclear rules for the sequencing of the steps in a system (i.e., unclear precedence relations).
• Uncovers problems with aliases in the naming of data and processes – an object being referred to by more than one name across different sections in the specifications or two or more different objects being referred to by the same name.

Read our white paper on achieving maximum code coverage.

See us in action, Register for a Webinar or a Live Demo.