The Simple and Effective Way To Deliver Clean Software: Hypothesis-Based Testing

Today, most clients want software that is clean and delivered rapidly and effectively. Users want the software to work perfectly right from the first time and continue working as expected, without any glitches. Developers tried to make this possible through a traditional testing process which improved the quality of the application. However, many times,  defects will escape the eyes of the testers, resulting in customer dissatisfaction and high maintenance cost.

Hypothesis-based Testing Explained

Hypothesis-based Testing (HBT) has emerged as the best solution to avoid this. HBT is a scientific personal test methodology that is powered by a defect detection technology. It enables an individual to rapidly & effectively deliver “Clean Software”. The major advantage is the fact that while all traditional testing methodologies are focused on activities that are driven by processes that are powered by tools and are dependent on the experience of the developer, HBT is based on a defect centric quality growth model, focused on the goal and then activities.

In clearer words, HBT operates on the theme of hypothesizing potential defects that can cause loss of expectations and proving that they won’t come into existence”.  HBT fits any development methodology and weaves it into the organizational testing process and practice. It is powered by STEM 2.0 (STAG Test Engineering Method) a personal system of disciplines enabled by a scientific core. Broadly speaking, HBT works in six stages.

Six stages of HBT

Stage #1: Understand Expectations

This stage indicates how well the product delivers the needs (features that allow the job to be done) of an end-user.  This also denotes the quality of the software/system. So, a key responsibility of an Effective tester is to understand:

  • The Marketplace
  • Various types of customers and end-users
  • Deployment environment
  • business requirements
  • expectations of each type of user

Stage #2: Understand the context

In this stage, key criteria are to understand technologies, architecture, features of the application, and attributes. Also important is to prioritize the end-users in terms of the successful deployment of the final system. This should be done while subsequently ranking the importance of features/requirements to each of the end-user types. This will lead to the identification of the expected value of measures for each attribute, leading to a concentrated effort in implementing the high ranked features as per customer requirements and identifying the possible potential defects in these features.

From stage 1 and 2 cleanliness criteria is achieved which provides a strong basis for Goal- focused- testing.

Stage #3: Formulate a hypothesis

This stage is also called the structured and scientific approach. This will focus on the properties that the final system should have to ensure the proper use of data, business logic, structure, environment, and usage.  Some of the potential defect types (or areas in which defects were focused upon) in this stage are:

  • Data validations
  • Timeouts
  • resource leakage
  • calculations
  • storage
  • presentation
  • Transactional

This phase helps in grouping the potential defects (PD) as potential defect types(PDT) and map them to requirements. The outcome of this stage is the Fault Traceability matrix.  Test cases are mapped to the corresponding requirements to form the Requirement traceability matrix, thus potential defects are mapped to the test cases. This allows us to understand the intended potential defects that can indeed be uncovered.

Stage #4: Devise proof

This stage prepares the test strategy and test plan documents and also identifies relevant testing techniques (TT) required to find PDT, to evaluate test scenarios and test cases, and define measurements.

This stage also categorizes test cases at different quality levels (eg: QL1, QL2, etc) which will result in:

  • Excellent clarity
  • Purposeful ie. defect oriented
  • clear insight into the quality
  • higher coverage

Stage #5: Tooling support  

The objective of this stage is to analyze the support that we need from tooling to perform the tests. This includes automation scenarios that deliver value and ROI.  In this stage, the following activities are performed:

  • Tooling benefit analysis to identify the scope of automation for our application
  • Assess Automation complexity
  • Identify the order in which scenarios needed to be automated
  • Evaluate existing tools for suitability
  • Design a good automation architecture that provides for maintainability
  • Develop scripts, debug and baseline scripts

Stage #6: Assess and Analyze

In this stage, the tester can identify the test cases/Scripts to be executed. The tester will execute test cases, record outcomes, defects, and status of the execution, analyze the execution results, calculate metrics, quantify quality, identify risk to delivery, update test strategy and then test plan document, scenarios, and test cases accordingly.

Advantages of HBT:

  • Reduces post-production defects and thereby maintenance cost
  • Higher test coverage
  • Defect leakage reduction from early stages
  • It is possible to define an objective quality growth model
  • The overall productivity is boosted since HBT helps in selecting an appropriate tool

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top