8

We have to deal at times with requests where a prospective customer is approaching us for some work and wants to know how we do testing. Generally what we hear is a high level statement (or one liner to be specific) such as:

  • Application x is being ported from platform x to y and we would like to know your test strategy.
  • We are starting with mobile apps development and would like to know how you can help us with quality.

I don't feel this much information is enough to get anywhere close to strategy or plan. I generally tend to initiate a dialog with the prospect by preparing a list of questions depending on how much information I can gather from people around me (who are involved at this stage) and my own experiences. I try to understand the business case for such an effort, the technology stack, business domain and its complexity, test objectives, and few other things. The answers to these questions raise more questions and it goes on like this for a while.

What are some of the more efficient ways to handle such situations? We have tried with limited success in the past to prepare a generic strategy that we can refer to at such times (explaining our processes and tools and keeping them independent of any business case), but I sincerely feel that every such request has its own context and the reply needs to keep that context in mind rather than falling back on one set of guidelines (even within the organization our strategy, tools, and to an extent processes differ depending on the type of project). The problem is that we have very limited information to start with and at times the prospect is not willing to wait for the information exchange cycle. Any ideas/suggestions?

8

I would suggest that your potential customers are not looking for a detailed 'test strategy' per se, what they likely are asking for is your company's capabilities and possibly capacity to scale.

For example, wrt to mobile app testing I would want to know if you are capable of running tests on emulators and devices, can you automate those tests on both emulators and devices (perf, stress, battery testing), what are the variety of devices you test on, how many different MO's around the world do you engage, do you have a faraday cage or how do you simulate low/no bandwidth, etc.

Of course, applications are different and product owner's have their own interpretation of quality. But, there are also some commonalities between some types of apps (e.g. games, utilities, word processors, etc). You might consider explaining at a high level your capabilities to test the type of app and general approaches used and then follow up with specific questions about the uniqueness of their application and their expectations of quality, and what they expect from the business engagement.

  • +1 @Bj liked your answer a lot and it comes really close to what I think should be the right answer.although we did tried explaining the general approaches by means of a document which didnt went very well. – Rajneesh Jul 21 '11 at 15:24
  • Doc's might draw prospective clients, but in a meeting those clients don't want to read a prepared document. I suspect your customers want to "hear" you (not a canned response) in order to gain confidence and trust that you can do the work they expect. One thing I left out; you might also describe examples of similar projects you've successfully done in the past and how they were conducted (without mentioning specifics if under NDA). – Bj Rollison Jul 21 '11 at 16:07
3

Sounds like you could with a course in Rapid Software Testing

It gives you the tools to ask pertinent questions in order to evaluate a product and provide information to the customer regarding the product.

The slides are available on James Bach & Michael Bolton sites, but the greatest benefit comes from attending the course.

Basically, you use a set of heuristics (guidelines) which guide your questioning in order to get the info you require.

Mapping the answers on a mindmap then helps you to understand the bigger picture & relationships.

Agree with you that a generic strategy probably isn't the most suitable due to the different contexts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.