The Many Facets of Software Testing – A Hierarchical Approach

Automated User Acceptance Testing – An Oxymoron?
August 31, 2017
Hierarchical Testing – What are you Testing? and Why?
September 6, 2017

The Many Facets of Software Testing – A Hierarchical Approach

Do a quick search on “Software Testing” and you will receive a vast number of results. The majority of these focus on a single approach to testing, and many will infer (or even explicitly state) that the given approach will solve most, if not all, of your software woes.  Practical experience over the years has demonstrated this to be false.

Software development is a multi dimensional and complex endeavor. It should not come as a surprise that any comprehensive approach to validating the software will also be multi dimensional and complex.  Earlier this year I published a series of posts related to testing the various aspect of the entire Application Life Cycle including:

  • Requirements Gathering
  • Architecture
  • Design
  • Implementation
  • Quality Assurance
  • Maintenance
  • Defect Management
  • Deployment
  • Operations

In this series, I am going to narrow the focus to those aspects that pertain directly to the code and examine elements in greater detail. To accomplish this, two key dimensions will be examined.

The first dimension is the Domain. This dimension tends to be more a set of discreet elements rather than a continuous spectrum.  Most of the focus in many organizations is on the Functional Domain: “Does the item under test perform the actions as defined in some specification?”.  While this is clearly a critical area of testing, other domains such as Design (which will be further broken down), Performance, and others often are the long term root aspects of the overall success or failure of a given effort.

The second dimension is the Integration Level. This dimension begins with the smallest possible elements, each tested individually; it ends with the entire system being treated as a single entity. There are a number of key considerations as one moves along this axis including: the point in time where a given type of testing is possible, the scope and bounds of possible tests, and the effective selection of tests which minimize unnecessary duplication of effort.

These two domains will allow us to create a grid that provides a view of the testing ecosystem. Analysis of this grid will help identity the earliest point in time a problem can be detected, potential waste caused by duplication, risk identification and other data points that enhance the ROI of our testing investment.

Comments are closed.