Rapid Testing


Rapid Testing is a powerful technique that can be used to complement conventional, structured testing. It is based on exploratory testing techniques and works well when there is too little time to obtain full test coverage with conventional methodologies. Rapid Testing finds the biggest bugs in the shortest time and provides the highest value for money of any testing methodology.

Why is it Necessary?

In an ideal world Rapid Testing wouldn't be necessary. However, in most development projects there are a number of scenarios where an instantaneous assessment of the product's quality is important. Examples include:

  • For a 'Proof of concept' test early in the development cycle
  • Before or after migration from development to the production environment
  • Sign-off of development milestones to trigger funding or investment
  • Prior to public release or delivery to the customer

Although most projects undergo continuous testing, this does not usually produce the information required to deal with the situations described above. In most cases, testing will be scheduled to end just prior to launch. It's also hard to apply conventional testing techniques to software that's incomplete or subject to constant change. At times like these Rapid Testing is ideal.

What is Wrong With Conventional Structured Testing?

Structured testing is a vital part of any development project but it cannot meet all quality assurance objectives. Its primary objective is usually affirmative testing – that is, to verify that the software does all the things it is supposed to. However, software is now so complex that there is often a seemingly infinite number of permutations of the data variables. Variations in the time domain can add another layer of complexity.

Of course, people don't always follow the neat user journeys laid out in test plans. It's also important to identify undesirable behaviour. The number of permutations associated with undesirable behaviour means the time required for analysis, scripting and execution is unviable, and could only be reduced if the tester knew in advance what the faults were likely to be.

How Does Rapid Testing Work?

Rapid Testing is based on exploratory testing techniques, which means that the tester has a general test plan in mind but is not constrained by it. The plan can be adapted on-the-fly in response to the results obtained for previous tests. The downside is that it is not possible to guarantee total test coverage, but the benefit is that a skilled tester can quickly home in on faults that would have eluded a scripted test. We often refer to exploratory testing as 'expert testing' as it requires a high level of technical knowledge and experience to be effective.

Rapid Testing extends the exploratory concept by making judgements about what faults to report and the level of detail to record. Once a fault has been identified, the time taken to investigate and document it reduces the time available to find other faults, so the tester may fail to find the serious faults if they spend too much time reporting less important issues. We refer to this as the 'quality threshold' and it is fundamental to the effectiveness of Rapid Testing. Many testers find it an alien concept but it is a necessary one.

The tester will consult with the customer to determine the initial quality threshold, but it is often necessary to vary it during the course of testing depending on the product quality. If the overall product quality is good it may be possible to reduce the threshold and investigate the less serious faults.

Quality Criteria

Quality Criteria is another important concept in Rapid Testing.

Have a look at the checklist below to prioritise your quality criteria. We've covered the criteria for most web-related and standalone applications, but you may need to add more, depending on the nature of the project.

  • Link integrity
  • Security
  • Java Script
  • Usability
  • Page content
  • Spelling and grammar
  • Accessibility
  • Form controls
  • Design consistency
  • Compatibility
  • Multimedia content
  • Stress testing
  • Default settings
  • Functionality
  • Search functions
  • Java and ActiveX
  • Boundary testing
  • Cache testing
  • Navigation
  • Performance
  • Form data validation
  • Printing
  • Cookie testing

Tell Me More

Our Operations team would be pleased to discuss how these techniques can be applied to your projects. They can be contacted via the form on the Contact Us page.