For several years I’ve told our customers that we begin test planning by learning about their business objectives. A VP in product development told me that he had no problem discussing their business goals with me, but surely such a discussion had nothing to do with testing. He said “I’ll give you the requirements; I’ll tell you when I need to know if we have met those requirements: all I want from you is to create test cases validating my requirements, and how long it will take you to run them.”
Maybe he tells me his business objective is to gross $20M next year. That doesn’t help me. I need to know how he plans to get there, and what part his software plays in those plans. Maybe he’s selling day-trading software at $30K per system. Maybe he’s developing software to monitor POS transactions at 36 of his stores in 4 states. In the first instance, which is a sort of product development, he’s spending testing money up front that he hopes to recoup through product sales. In the second instance, a kind of IT tooling, he’s hoping to optimize business processes in order to reduce overhead costs. They differ in what to test and how to test it. In the first, delivering feeds from several markets in real time is going to be a major criterion for quality; in the other, getting it in real time isn’t as important as interfaces to inventory databases, a bookkeeping system, and credit card companies.
A company won’t know if it’s meeting its business objectives unless those objectives are measurable.
So the objectives have to be translated into dimensions. Verifying delivery of live data in real time can be measured in units of time. Tests can be written whose output is expressed in units of time so that output can be compared to target values. A short way to say it is that quality objectives must support business objectives.
If that VP in product development did not write requirements that reflected quality objectives that would support his business objectives, even if we had delivered test cases in a day and executed them in only 15 minutes, in a very real sense he would still be clueless regarding ship-readiness. Being ship-ready cannot just be about passing tests. The tests need to be meaningful – that is, they must verify that specific functions complete actions necessary to the fulfillment of business objectives. It is much easier if requirements have been written for that purpose. All this must be considered for test planning.
Related Posts
Regulatory Compliance and Software Quality Assurance Creating Sanity Amidst Test Methodology Madness – Webinar Series My interactions with Customers – Independence of Testing doesn’t mean many dismissed defects MindTree Vlogs: Role of Independent Testing in the Manufacturing industry Can testing link business risks to the end user satisfaction?
Recent Posts
Is vmUnify just a provisioning solution? Distributed Agile and Work-Life Balance Customization in SaaS – Who draws the line? Smart Grid Applications go on Cloud What is the purpose of testing? View all
Most Viewed
Different Views on Consulting (1520) What is Consulting? (1333) B2B Digital Marketing (1263) A fresh look at metrics and the marketing funnel (1103) Can You Entrust Your Services Partner With Your Demand Reduction Goals? (694) View all
Most Commented
What is the difference between Marketing and Sales? (24) An inbuilt mechanism for innovation: organic & ecological (16) Everything That’s Marketing (16) Mumbai Dabbawalas (13) Corporate Blogging: It’s All About Engagement (13) View all
Vlog
Creating Sanity Amidst Test Methodology Madness – Webinar Series Transforming Test Organisation MindTree Vlogs: Role of Independent Testing in the Manufacturing industry A Look Back and A Look Ahead Some Brands Never Get Old View all
Cartlog
What’s in it for me? (WIIFM) When you are an expert on something, where do you learn from? Mantras for Communities FAA-some Avoiding the Death March of IT Delivery View all





MindTree Blog Archives

Subroto Bagchi



eduardo says:
¿qué empresas han fracasado por mala realizacion de objetivos?
¿qué son los objetivos generales y departamentales?
John Scarborough says:
Except for businesses that fail deliberately in order to get a tax deduction, businesses seek to at least survive. That would be the most basic objective. So, any business that fails to survive may be said to have failed to realize at least one business objective.
But I was talking about objectives beyond survival. A mission statement conveys a business’ purpose and ideals. Objectives commit a company’s purpose and ideals to action; together, all the
objectives that have been formulated comprise a strategy. Objectives need to be created for every domain of action in which survival is at risk: finance, environmental sustainability, ethical
responsibility, regulatory compliance, material provision, people, etc. If those objectives are not stated in a way that their realization can be validated by qualitative comparison or quantitative measurement, the company will not know whether its
strategy is working.
Suppose a company develops a new cellphone whose differentiating factor is designed to be superior connectivity. To test it, you need to specify an area of connectivity, and show that your cellphone beats your competition in that area, say percentage of cell-to-cell transitions without drops. You could say that the general business objective was to provide a better phone than your competition. The departmental business objective might be to ensure that your cellphone drops fewer calls in cell-to-cell transitions than your competitors’ cellphones.
What often happens is that the test organization is asked to test something that is not relevant to the business objective. For example, the test organization for this hypothetical company may spend all its testing money verifying that its customer billing software works, and neglect crucial aspects of cell transitions. I am making this example up, but I have seen real-world situations that are worse.
Best -
John