Clarifying
Project Complexity - Many information technology
projects carry complexity that often goes unrecognized during the
early stages of project initiation and requirements analysis. This
complexity is inherent in the business system being described by the
project requirements. Because such complexity has the greatest impact
on the project during technical design, it is often overlooked during
earlier project planning and activity. However, the complexity is
a significant contributor to the effort required to build and test
the system, and to the size and cost of the system. As a result, projects
are more likely to conform to their schedules and budgets if these
business complexities are built into the project charter and plan
from the beginning. This guide describes four quality-based patterns
built on the idea that any system is a mechanism for turning customer
requirements into satisfactory conformance. They allow simple quality
management principles to be used to quickly pinpoint areas within
the project scope that will experience increased complexity, and therefore
higher need for project resources. These areas can then receive increased
scrutiny during project planning.

Understanding
Requirements - The purpose of requirements definition
is to establish a common understanding of the requirements for a system
between the customers and the project team. This involves clarifying
the problem and business case associated with the project, and the
specification of the full functional and technical requirements to
be met to solve the associated business problems. Requirements analysis
seeks and documents the business problems to be solved by the project
based upon the collection of concerns, issues, needs, and requests
from all project stakeholders throughout the organization. This guide
outlines two goals: 1) defining the business problem to be solved
and the rationale that determines the importance and value of the
solution to the business, and 2) describing what needs to happen in
order to solve the defined problem; and the criteria that should be
used to determine if the project reaches successful implementation.

Setting
Test Objectives - Testing covers the broadest
range of activities required to both verify and validate deliverables
associated with the project efforts and the final system components
delivered into production. This guide cover the two perspectives on
testing: 1) verification that addresses the issues surrounding
the correctness of the deliverables produced with respect to previous
project deliverables and general IT standards and procedures, and
2) Validation that addresses the issues surrounding whether the deliverables
produced will actually meet the needs of the user community to which
they are targeted. Verification asks the question "Did we do
it right?" Validation asks "Did we do the right thing?"
Ultimately, validation of the results of an e-business project is
the goal of this test plan. However, experience shows that deliverables
that can't be verified are difficult to impossible to validate.

Developing
Test Plans - Even though testing is rarely as
scientific and comprehensive as we'd like it to be; it always pays
to plan testing as if it were going to be very scientific and comprehensive.
The reason is that it helps to put any given test case into the fullest
picture of the system and the testing risk being managed. This guide
defines how to create such a plan; but it only works if you write
the plan down! Make sure you create a Test Plan document. Yes, it
will look more rigorous than the actual process you follow during
testing, but the results will be better if you take a little extra
time to formalize the planning. Once documented, we can focus earliest
on the parts of the system that are most likely to fail, and continuously
adjust the plan accordingly.

Planning
Test Strategies - The test strategy maps techniques
for testing against the various types of verification and validation
test types available and attempts to prioritize how testing resources
will be allocated generally across the project. Each individual situation
is ultimately evaluated on a case-by-case basis, but the general strategy
documents the perceived risk areas being addressed by the test plan.
This guide includes a general prioritizationmatrix that helps software
teams plan integrated testing throughout the development process.