Non Linearity in Software Testing - Introduction
Most IT Services vendors have grown in a linear model, wherein revenue growth is directly proportionate to the employee strength. First ISO, then CMM and now CMMI standards and frameworks aided and continue to aid linear growth, as they introduced the use of standardized software management processes across the lifecycle from conception to eventual retirement of systems.

The Capability Maturity Model (CMM) was originally developed as a tool for objectively assessing the ability of US government contractors' processes to perform a contracted software project. But the model was soon widely adopted in software and application development organizations around the world, and most notably by Indian organizations offering offshore outsourcing services. Initially it was adopted by Indian IT service vendors as a means for proving their capability to their US customers, but soon these organizations realized that the model’s true value was in helping them scale (and scale rapidly) in what is essentially a people driven business.

This blog entry discusses how nonlinearity can be implemented in the area of software testing that will enable a decoupling of revenue growth from employee strength. Testing services have become highly commoditized, and all commoditized services today are under constant pressure to reduce service cost. This constant pressure on cost reduction necessitates a change in how testing projects are being executed today; this paper proposes the implementation of nonlinear techniques that contribute towards the decoupling of revenue earned and FTEs utilized.

Linearity in Software Testing
Linearity has created giant organizations, as the only way to grow revenue is to add to employee strength. For every billion dollars of revenue an offshore software service provider typically needs between 20000 to 23000 employees, this number can be much higher if BPO services are also part of the organization’s service offerings. While there is still sufficient robustness in the ability of large organizations to manage large numbers of employees, a time will be reached when size can lead to implosion of an organization.

Clean Slate Starting Points
In the linear model the starting point for any testing project is perpetually a “clean slate” or “Greenfield”. All estimations of effort required are based on the assumption that we need to build from scratch. Once a “clean slate”, starting point is chosen there will be a limited number of logical conclusions to an RFP response. It’s easy, however, to rely upon “clean slate” starting points simply because they are what project managers have been used to. “Clean slate” starting points limit us from finding a much better answer, and perpetuate linearity.

For example, imagine a service provider who believes that it must raise revenues to increase profits. It tries multiple methods including product bundling, gimmicky advertising, increasing coverage etc., It forgot however that it could also reduce costs to increase profits, and in doing so missed what could have been much less expensive, less demanding options. “Clean slate” starting points are similar in that there no initial focus on reducing the required efforts.

Non-Linearity in Software Testing
The decoupling of revenue earned from FTE’s deployed can only be achieved through a nonlinear services delivery model. A nonlinear services delivery model is based on constantly working to change the “starting point”, by ensuring a “clean slate” situation is rarely encountered. In the context of software testing, this can be achieved by creation and use of:

1. “solution accelerators”

2. Innovative program management processes and delivery models, an

3. Outcome based pricing models.

Solution Accelerators
Solution Accelerators as the name suggests, help in accelerating the testing of applications and business solutions while at the same time reducing the effort required for testing. These accelerators draw upon TechM’s expertise of providing testing services to telecom service providers for over 20 years. The concept of solution accelerators is not new; in this blogpost we will expand the definition of solution accelerators to cover not just reusable code and best practices but a range of reusable artifacts and delivery models. The concept of reusability is also not new, but once again here we will expand this definition to include example based solution accelerators that may include artifacts, methodologies and models that help shorten the testing prep time and help bring customers’ solutions to market quicker and with higher quality. This involves stress on:

1. development and deployment of intellectual property (IP) components coupled with

2. a movement to create a set of solution accelerator libraries and

3. ensure widespread awareness and usage of the components.

The core principal is that experiential knowledge gained by employees while executing testing projects is sought to be turned into corporate knowledge as example based solution accelerators. Examples of what “testing solution accelerators” are:
· Specially created IP/reusable components resulting out of planned R&D efforts or chance innovation, and

· Example IP resulting out of experiential knowledge gained by employees while executing projects

· Automation Libraries (we have 11 such libraries in TechM)

· Fully/Partly Reusable Test Scenario/Test Case Repositories

· Test Ideas Catalogues

· Estimation Tool Kits

Innovative program management processes and delivery models
TechM’s project management processes are aided by practices in line with the SEI CMM Level 5. These processes address key aspects of a project across the project life cycle, from Project planning, Project monitoring, reporting procedure and review mechanisms, Project risk management, Configuration management, Change management, Issue escalation and resolution and Intra-engagement communication with client managers. Typically today’s processes focus on achievements and metrics at a project level, and these are periodically aggregated at a company level as ‘baselines’ on productivity and other such related metrics.

In addition to this, we need to add focus on integrated metrics across projects and at a program level with the objective of uncovering opportunities for non-linearity. There are many excellent examples within TechM of “cross program” engagements, like the COLO Centers, TAC or Test Automation Centers, and Test Environments managed as Data Centers.

Program-level management metrics are not so much “capability centric” as are project-level metrics, these metrics are more “outcome centric” and focus on testing programs aligning with and measuring business value delivered as measured by RTF (right first time), CTR (cycle time reduction), E2E business process validation effectiveness.

Outcome based pricing models
Outcome based pricing models are another means of decoupling revenue from actual effort or FTEs deployed, as revenue accruals are directly dependent on actual business outcomes achieved rather than on the number of FTEs deployed for achieving the outcome.

In the area of software testing however, the emphasis most often is on technical outcomes rather than on business outcomes. These models typically operate on the principal of guaranteeing that outcomes will conform to a pre-agreed performance band, with failure to do so attracting financial penalties. Most also have a reward mechanism that rewards achievements that are better than targeted performance.

These models are premised on taking all the fragmented horizontal shared testing services and consolidating them in such a manner to enable a single point ownership for the business outcome of a particular process. Nonlinearity is achieved when the consolidation and single point ownership is then used to facilitate reusability across applications, networks and devices that are required to work together to deliver the process outcomes.

So What Next?
Well for starters, let’s get your view on what else can contribute towards bringing about nonlinearity in software testing. Through this blog, I encourage you to share your thoughts and ideas on what can be done, or what you are doing within your own project now, which is a step in implementing non-linearity.

As follow-up, look for my next blog post that will discuss a typical roadmap for implementing nonlinearity and that will discuss detailed steps for each of the three key areas identified in this post.