Business BASIC(s)
Some years back a store near me started having a going-out-of-business sale. Six months later it was *still* having a going-out-of-business sale. A nearby newsstand which was also closing for good mocked it with signs that read "Come here for a real going-out-of-business sale" and "We're really going-out-of-business". A month after the newsstand was gone. It was another four months before the store actually closed.
Several months later an empty storefront a few blocks down the road sprouted signs announcing the Coming Soon of a shop whose name sounded suspiciously similar to the store with the year-long going-out-of-business sale. And sure enough, when it opened it had exactly the same types of merchandise and exactly the same staff. Some twelve months later the going-out-of-business signs went up. The shop took only six months to shut down this time.
And then, seven blocks in the other direction, signs went up in yet another storefront. Two months passed while the space was renovated, and then the store opened for business. All the same stuff. All the same people.
This time it was only a month before the going-out-of-business signs appeared. Eight months later they started claiming the Very Last Day, Honest would be...the day before they started claiming this. Two weeks later the place was empty.
A month later they were back. The name of the store had changed, neither its contents nor its staff had. They didn't even bother to take the "40% off all baskets" sign from the previous incarnation out of the window.
I don't pretend to understand their business model, which appears to be:
100 Open a store
200 Wait some random number of months
300 Start going out of business
400 Wait some random number of months
500 Close for good
600 Wait some random number of months
700 Reopen somewhere else in the neighborhood
800 GoTo 100
I do however understand my team's business model. This knowledge helps me determine what to test, how to test, and when to test.
Understanding the business reasons for bringing my application to market helps me organize my testing. Which features must be tested and which can be ignored are likely different if we are targeting newbie consumer types than they would be if we are pursuing people who manage server farms. For example, usability is typically important in the former case, whereas scriptability is likely more important in the latter case.
Knowing who we expect to buy our program and how we expect them to use it helps me decide which types of testing to do and which to not do. The importance of stressing the system or of comprehensive test automation (to pick two at random) generally changes depending on how fast we plan on gaining market share, how often we plan on releasing updates, and how defect-tolerant our customers are. For example, load testing is probably more important if we plan on blanketing the universe with install CDs than it would be if we will gate user sign-ups.
Having an idea of which markets we are entering and how we are approaching each of them helps me decide when to do whatever testing I decide to do. Dates for product announcements, press and analyst road shows, and availability targets all place boundaries by which certain functionality must be tested and certain types of testing must be complete. For example, the release of a consumer product may be timed such that it will be in stores in time for the winter holiday selling season. Server-side components of that product, however, may not need to go live until mid-December, since most purchases of the product will be wrapped and hidden from prying eyes (and so not being used) until then.
How does one go about learning about one's business plan? Ask your CEO! Or talk with someone on your marketing team - which may or may not be less intimidating than chatting up your senior executives. <g/> Or, depending on the size of your team, you may have one or more people dedicated to creating and managing the business plan.
Regardless of their role or title, someone somewhere will be able to explain and tell you all about the business plan for your product. If you can't find that someone, be very afraid!
*** Want a fun job on a great team? I need a tester! Interested? Let's talk: Michael dot J dot Hunter at microsoft dot com. Great testing and coding skills required.