“I bought this guide a few days ago to prepare for my interview with Oracle. Many of the questions they asked me were from this guide. I found this book absolutely great!”
Given a question of trade-off between time to test the product and marketing the product things to consider are :
where to draw a line between the product can be shippable and not shippable.
Shippable products can have bugs, but the user experience scenarios are working correctly and if it won’t create a hazard or stop to user experience, the product can be shipped. So testing should consider prioritizing
the show-stop scenarios, like crashes, hanging, memory corruptions, scenarios for continuity in experience of user etc in top priority and ship the product, then proceed further.
major software systems can suggest that they failed coz the developement team allocated less time for testing then developement. For a program manager it is necessary to put equal amount of time for testing the product as developing the system if u want ur organization or the product to stay in the market.
I think it depends more on the market situation…many a times, in the hi-tech market, you are going to be able to sell only if u are the first guy out with the product. It is really really important to be the market pioneer. If the market demands it, u better get the product out and ask the developers and testers to go to hell. Getting a prototype of the product into the market is the least you can do. At the same time if you can afford the time ( no pressure from competitors, new entrants, subsitute products or buyers ) then do as much as testing as possible. The balance between testing and the release should totally depend on the market!
First, try to re-think about the scope of features. Take away some features, and buy time to test.
Second, Set the satisfaction level of testing to be lower. For example, may be u orignally set the number of minor bug is below 10, number of major bug is below 2. (or using precentage). Now, due to time limited, put number of minor bug is below 15. and number of major bug below 5.
You cannot ship a half-baked product to market. It has to be tested for critical bugs thoroughly, there is no question of dropping the white-box QA cycle. However, if time to market is important, the product need not undergo some of the other common tests such as usability testing, acceptance testing, system testing, negative testing etc. However if it is part of an integrated suite, integration testing is important.
You can shave off some of the non-essential items of testing from the test cycle and ship the item to a first group of beta testers (as Microsoft does for most of its products). However no product should be released in an alpha stage to market, unless we are talking about open source here, which is a different story altogether.
if the architecture and design of a project is as close as to ideal(say 90% ok).then no need to think about tradeoff between time spent on testing and marketing a product.testing should be done parallel to development.
Given a question of trade-off between time to test the product and marketing the product
things to consider are :
where to draw a line between the product can be shippable and not shippable.
Shippable products can have bugs, but the user experience scenarios are working correctly and if it won’t create a hazard or stop to user experience, the product can be shipped. So testing should consider prioritizing
the show-stop scenarios, like crashes, hanging, memory corruptions, scenarios for continuity in experience of user etc in top priority and ship the product, then proceed further.
TRADEOFF: between the amt of testing that can be done. 100% coverage cant be done
major software systems can suggest that they failed coz the developement team allocated less time for testing then developement. For a program manager it is necessary to put equal amount of time for testing the product as developing the system if u want ur organization or the product to stay in the market.
in microsoft’s case..ship it out..who cares about bugs…just fix it in the next release.
I think it depends more on the market situation…many a times, in the hi-tech market, you are going to be able to sell only if u are the first guy out with the product. It is really really important to be the market pioneer. If the market demands it, u better get the product out and ask the developers and testers to go to hell. Getting a prototype of the product into the market is the least you can do.
At the same time if you can afford the time ( no pressure from competitors, new entrants, subsitute products or buyers ) then do as much as testing as possible.
The balance between testing and the release should totally depend on the market!
First, try to re-think about the scope of features. Take away some features, and buy time to test.
Second, Set the satisfaction level of testing to be lower. For example, may be u orignally set the number of minor bug is below 10, number of major bug is below 2. (or using precentage). Now, due to time limited, put number of minor bug is below 15. and number of major bug below 5.
You cannot ship a half-baked product to market. It has to be tested for critical bugs thoroughly, there is no question of dropping the white-box QA cycle. However, if time to market is important, the product need not undergo some of the other common tests such as usability testing, acceptance testing, system testing, negative testing etc. However if it is part of an integrated suite, integration testing is important.
You can shave off some of the non-essential items of testing from the test cycle and ship the item to a first group of beta testers (as Microsoft does for most of its products). However no product should be released in an alpha stage to market, unless we are talking about open source here, which is a different story altogether.
if the architecture and design of a project is as close as to ideal(say 90% ok).then no need to think about tradeoff between time spent on testing and marketing a product.testing should be done parallel to development.
Leave an Answer/Comment