MindTree’s 5 Principles of Software Testing

Posted by MindTree Blog Archives in

 Testing

Sep 3, 2009 | Total views: 40

0

MindTree Blog Archives

More articles by the author

Here is a customer who wants us to provide testing services for their software. They expect us to know how to plan, organize, execute and sustain those testing services at an affordable cost, with such efficiency and acumen that our customer can increase their net revenue through ongoing deployment of their expanding and continually changing application portfolio. Why are we confident that we are the best qualified vendor of those testing services?

It’s not because of MindTree’s collection of automation frameworks, auditing tools, quality checks, core libraries of test cases, application handbooks, risk mitigation techniques, governance models, MINTs, accelerators, and effective training curricula. No. What gives us an edge over our competition is our adherence to MindTree’s 5 principles of software testing:

   1. attention to the business case (knowing the business objectives named by customer stakeholders, but also understanding its financial aspects in terms of profit and loss to the company or its shareholders);

   2. inquiry into contingencies in our client’s organization, schedule, competition, history, platform, staffing, and alternate technologies that require intelligent adjustment of our frameworks, methodologies, and best practices;

   3. alignment of measurable quality objectives to the System Under Test’s business objectives;

   4. orienting the entire test effort, in all its aspects, to those quality objectives; and

   5. verifying the achievement of those objectives through reporting of process checks, production metrics, and quality metrics

Each testing strategy (and resultant test plans and practices) will necessarily be different. A keyword-driven, data-driven test automation framework that has been proven in the testing of one system may provide the basic architecture for testing several other systems, but 20% of its code may still require revision. The reverse engineering approaches used in one project can be leveraged for other projects, but not without intelligent adjustment.

First the principles, then the model. From the model, the application; finally, the harvest.