Testing Without a Formal Test Plan
A formal test plan is a document that provides and records important information about a test project, for example:
- project and quality assumptions
- project background information
- resources
- schedule & timeline
- entry and exit criteria
- test milestones
- tests to be performed
- use cases and/or test cases
For a range of reasons -- both good and bad -- many software and web
development projects don't budget enough time for complete and
comprehensive testing. A quality test team must be able to test a
product or system quickly and constructively in order to provide some
value to the project. This essay describes how to test a web site or
application in the absence of a detailed test plan and facing short or
unreasonable deadlines.
Identify High-Level Functions First
High-level functions are those functions that are most important to
the central purpose(s) of the site or application. A test plan would
typically provide a breakdown of an application's functional groups as
defined by the developers; for example, the functional groups of a
commerce web site might be defined as shopping cart application,
address book, registration/user information, order submission, search,
and online customer service chat. If this site's purpose is to sell
goods online, then you have a quick-and-dirty prioritization of:
- shopping cart
- registration/user information
- order submission
- address book
- search
- online customer service chat
I've prioritized these functions according to their significance to
a user's ability to complete a transaction. I've ignored some of the
lower-level functions for now, such as the modify shopping cart
quantity and edit saved address functions because they are a little
less important than the higher-level functions from a test
point-of-view at the beginning of testing.
Your opinion of the prioritization may disagree with mine, but the
point here is that time is critical and in the absence of defined
priorities in a test plan, you must test something now.
You will make mistakes, and you will find yourself making changes once
testing has started, but you need to determine your test direction as
soon as possible.
|