Risk-Based Testing: Test Only What Matters

By: Rajnish Mehta

Summary:
Rajnish Mehta writes that test teams needs to have a scientific way to support the business need of shipping a product out of the door. Risk-based testing is a practical approach for test teams to utilize as it allows them to think from a business prespective.

In today’s era, the IT industry is running on “fast mode” and the majority of stakeholders are looking for quicker solutions. The project management office is always hurrying to ship products out of the door. While there is nothing wrong in doing things this way, it does become a challenge for test teams who have to accept the fast-mode schedule and promote the product to production.

My recent experience with a retail client and its test team has shown me how desperately test teams want to meet deadlines while dealing with ongoing changes. In this instance, we had a big challenge in that the business had not prioritized its need.

In a situation like this all responsibility falls on the test team, which could easily become a scapegoat for shipping slipped defects to production. A delay in the upstream software development lifecycle (SDLC) process like requirements and development can make things worse. For my team, the stakeholder’s constant demand to make the product reachable to the customer was adding fuel to our fire; the test team was under tremendous pressure.

Being a solution provider, a test team must have a logical and scientific answer to the above challenge. Using a risk-basked testing (RBT) approach worked really well as the test team could deliver on the promise. While there could be many more factors when you assess the risk, I just chose two factors to explore in this piece for the simplicity of implementation and it’s easier to understand. With the approach we chose, our test team saved a big portion on the test execution effort; it allowed for great savings yet it delivered all that was important to the business.

All of us working in the IT industry are continuously looking for cost-effective solutions. Obviously, this means implementing the most logical solution that can bring lots of value with less effort. In my opinion, this solution is for all kinds and sizes of projects. Depending upon the industry, the risk factor may change but the concept remains the same; except, of course, if you are in the pace-maker industry and you have zero risk-taking ability.

Depending on the industry, we must always maintain medium-to-low open defects during production. For example, a company making pacemakers will have lower risk-taking ability than the financial industry, which has a lower risk-taking ability than the education industry and so on. One’s risk-taking ability depends upon the industry and then the application being designed within that company.

Some industry leaders are willing to take on known risks than delay time-to-market. I believe that in the IT industry, the QA team should find a way to support the thought of a faster time-to-market concept.

In order to achieve the goal of testing only that matters and achieving a faster time-to-market, we need to rethink testing scope. You might have some questions about doing so, which could include:

Do we need to test everything?
How do we reduce the testing effort?
When do we stop testing?
What is the best way to have a shorter test-phase cycle duration?
How do we be successful with more test cycles?
How do we get buy-in from management when we do not test certain test cases?
What metrics do we produce?

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/