Posts Tagged ‘Early defect detection’

Quality injection – Scientific validation of requirements

Monday, August 9th, 2010
domain knowledge. One of our Japanese customer threw a challenge – “How
can you use HBT/STEM to scientifically validate requirements without knowing
the domain deeply?” .
The core aspect of HBT is to hypothesize potential defect types that prove that
they do not exist. These are identified by keeping in mind the end users and
the technology used to construct the system. So how do you apply this to
validate a pre-code artifact?
We commenced by identifying the various stakeholders for requirement
document and then identified key cleanliness attributes. These cleanliness
attributes if met would imply that the requirements was indeed clean. We were
excited by this. We then moved and identified potential defect types that would
impede these cleanliness attributes/criteria.
Lo behold, the problem was cracked and we then identified the various types
and the corresponding evaluation scenarios for validating the requirements/
architecture document. We came up with THIRTY+ defect types that required
about 10+ types tests conducted over TEN quality levels with a total of SIXTY
FIVE major requirement evaluation scenarios to validate a requirement.
What we came up is not yet-another-inspection-process that is dependent on
domain knowledge, but a simple & scientific approach consisting a set of
requirement evaluation scenarios that could be applied with low domain skill to
ensure that the requirement/architecture can indeed be validated rapidly and
effectively. These ensure that the requirement document is useful to the various
stakeholders over the software lifecycle and does indeed satisfy the intended
application/product attributes.
We now have a unique solution “Clean Requirements Solution” that is an
adaptation of HBT to validate requirements.

Validating early stage pre-code artifacts like requirement document is challenging. This is typically done by rigorous inspection and requires deep domain knowledge. One of our Japanese customer threw a challenge – “How can you use HBT/STEM to scientifically validate requirements without knowing the domain deeply?” .

The core aspect of HBT is to hypothesize potential defect types that prove that they do not exist. These are identified by keeping in mind the end users and the technology used to construct the system. So how do you apply this to validate a pre-code artifact?

We commenced by identifying the various stakeholders for requirement document and then identified key cleanliness attributes. These cleanliness attributes if met would imply that the requirements was indeed clean. We were excited by this. We then moved and identified potential defect types that would impede these cleanliness attributes/criteria.

Lo behold, the problem was cracked and we then identified the various types and the corresponding evaluation scenarios for validating the requirements/ architecture document. We came up with THIRTY+ defect types that required about 10+ types tests conducted over TEN quality levels with a total of SIXTY FIVE major requirement evaluation scenarios to validate a requirement.

What we came up is not yet-another-inspection-process that is dependent on domain knowledge, but a simple & scientific approach consisting a set of requirement evaluation scenarios that could be applied with low domain skill to ensure that the requirement/architecture can indeed be validated rapidly and effectively. These ensure that the requirement document is useful to the various stakeholders over the software lifecycle and does indeed satisfy the intended application/product attributes.

We now have a unique solution “Clean Requirements Solution” that is an adaptation of HBT to validate requirements.

Rapidly understanding the usage profile

Thursday, April 29th, 2010

Understanding the rate and number of transactions probably on a real system is critical to ensure that the system is designed well and later sized and deployed well. Good understanding of the business domain is seen as a key enabler to arrive at the usage profile.

Operational profiling (A STEM core concept) is a scientific way to quickly arrive at a real life profile of usage. Good understanding of this concept alleviates the problem of lack of deep domain knowledge to understand the usage profile. This core concept consists of these key aspects:

  1. Mode – Represents a time period of usage e.g. End of month, where the usage patterns are distinctive and different.
  2. Key operations (features/requirements) used
  3. Types of end users associated with the key features/requirements
  4. Number of end users for each type of users
  5. Rate of arrival of transactions

In short, for a given mode, identify the end users types and their key operations and then identify the number of users for each type of user and then identify the rate of arrival of transaction. Employing this core concept allows us to think better and ask specific questions to understand the marketplace and the usage profile in a typical and worst-case scenario.

This allows us to get a better understanding of the usage and helps in identifying business risks and derive an effective strategy.

This is covered in “HBT.2 : Rapid Understanding of customer expectations”, a title in our HBT Series of workshops.

10x reduction in post release defects – Finest experience of applying STEM

Thursday, April 15th, 2010

This is about one of the finest experiences that STAG had with a global chip major where the early implementation of STEM yielded significant results. Our engagement with them was to setup an effective validation practice for their porting level API for video decoders. The customer had a great technical team and were involved in both development and QA. The challenge that they faced with their complex product that involved both hardware and software and later system integration on multiple real time OS on various platforms, was that of high defect escapes i.e. post-release field defects.

We spent about a month understanding their domain and the associated technologies. Post this, a detailed analysis yielded interesting data – test cases were primarily conformance oriented, coverage of test cases was suspect, escaped defects seem to propagate from early stages and finally the process of validation was loose.

Having understood the types of defects that were being found and the post-release defects, we figured out the various types of probable defects and the various combinatorial aspects that need to be considered to form a test case. We then staged the validation as consisting of three major levels, the first one at API level, then the next one at a system level, and the last level made up of a customer-centric level that involved using reference applications.

Applying the STEM approach to test design, the test cases were developed, yielding about 6000 test cases at level one and about 800 at the subsequent levels. Also, whereas the ratio of +ve vs –ve test cases was earlier towards the +ve side, after our re-design, the ratio shifted to 60%:40% at the lower level and about 85% :15% at the higher levels. Moreover, the test cases increased in number significantly by a factor of 1000%, allowing for a larger and deeper net to catch many more serious defects. Over the next 9 months, the rate and number of defects detected increased dramatically, resulting in post-release issues reducing by a jaw-dropping 10x times.

Once we solved the test effectiveness problem and increased the yield of defects, the focus shifted to streamlining the process by setting up proper gating in the test process and creating a centralized web based test repository, and finally setting a strong defect analysis system based on Orthogonal Defect Classification (ODC) method. This enabled a strong feedback system, resulting in shifting the defect finding process to earlier stages of SDLC and thereby lowering cycle time. Complementing this, we focused on setting up a custom tooling framework for automating this non-UI based software resulting in a significant cycle time reduction – an entire cycle of tests on a platform took less than 15 hours of time!

This has been one of the finest experiences that we had with STEM, and was a clear winner for STEM implementation. This was only possible because of the very mature engineering management staff of the customer, who were focused on systemic improvement and had systematic improvement goals.

What is to be noted is that our test team was NOT a team with significant depth of experience on the particular product domain. Applying STEM at a personal level, the team was able to understand what was necessary and sufficient for effective validation and complemented the strong technical team with mature defect-oriented thinking. This was an early case study for us to establish that a STEM based approach provided us with the right thinking skills for defect finding, rather than resort to a domain centric approach to defect finding.