Software testing

1. Introduction
1.1 SCOPE
The overall purpose of testing is to ensure the {xyz… application} application meets all of its
technical, functional and business requirements. The purpose of this document is to describe the
overall test plan and strategy for testing the {xyz… application} application. The approach described
in this document provides the framework for all testing related to this application. Individual test cases
will be written for each version of the application that is released. This document will also be updated
as required for each release.

Factors influencing test scope
 Size of project
 Complexity of project
 Budget for project
 Time scope for project
 Number of staff
 Why test at different levels
 Software development naturally split to phases
 Easily track bugs
 Ensures a working subsystem/ component/ library
 Software reuse more practical

      1.2 TEST OBJECTIVES
The quality objectives of testing the {xyz… application} application are to ensure complete validation of
 The business and software requirements:

 Verify software requirements are complete and accurate
 Perform detailed test planning
 Identify testing standards and procedures that will be used on the project
 Prepare and document test scenarios and test cases
 Regression testing to validate that unchanged functionality has not been affected by changes
 Manage defect tracking process
 Provide test metrics/testing summary reports
 Schedule Go/No Go meeting
 Require sign-offs from all stakeholders
   1.3 TESTING GOALS
The goals in testing this application include validating the quality, usability, reliability and performance
of the application. Testing will be performed from a black-box approach, not based on any knowledge of
 internal design or code.Tests will be designed around requirements and functionality.

Another goal is to make the tests repeatable for use in regression testing during the project lifecycle, and
for future application upgrades. A part of the approach in testing will be to initially perform
a ‘Smoke Test’ upon delivery of the application for testing. Smoke Testing is typically an initial
testing effort to determine if a new software version is performing well enough to accept it for a
major testing effort. After acceptance of the build delivered for system testing, functions will be tested
based upon the designated priority (critical, high, medium, low).
1.4 Quality
Quality software is reasonably bug-free, meets requirements and/or expectations, and is maintainable.
Testing the quality of the application will be a two-step process of independent verification and
 validation.
 First, a verification process will be undertaken involving reviews and meetings to evaluate documents,
 plans, requirements, and specifications to ensure that the end result of the application is testable, and
 that  requirements are covered. The overall goal is to ensure that the requirements are clear, complete,
 detailed, cohesive, attainable, and testable. In addition, this helps to ensure that requirements are agreed
to by all stakeholders.
Second, actual testing will be performed to ensure that the requirements are met. The standard by which
the application meets quality expectations will be based upon the requirements test matrix, use cases and
test cases to ensure test case coverage of the requirements. This testing process will also help to ensure
the utility of the application – i.e., the design’s functionality and “does the application do what the users
need?”

      1.5 Reliability
Reliability is both the consistency and repeatability of the application. A large part of testing an
application  involves validating its reliability in its functions, data, and system availability. To ensure
 reliability, the test approach will include positive and negative (break-it) functional tests. In addition,
to ensure reliability throughout the iterative software development cycle, regression tests will be
 performed on all iterations of  the application.


1.6.  Purpose of The Test Plan Document
    The Project QA/Test Plan is an Master Test plan that encompasses the entire testing required for a
project.  It is the highest level testing plan that documents the testing strategy for the project, describes
the general approach that will be adopted in testing , provides the overall structure and philosophy for
 any other required testing documents, and defines what will be tested to assure the requirements of the
product, service, or system (i.e., the deliverables) are met.

    Based on the size, complexity, and type of project, subsequent test plans may be created and used
during the testing process to verify that the deliverable works correctly, is understandable, and is
 connected  logically.  These test plans include the following categories and types.  Testing
areas/coordinators would have templates specific to these plans.
Types of quality assurance planning include:
     Process QA plans document how the project is meeting quality and compliance standards ensuring
     the right documentation exists to guide project delivery and corrective actions, and
     Requirements/application test plans document how the product, service or system meets stated
     business and technical requirements, and how it will work within the defined operational/business
     processes and work flow.
     The Project QA/Test Plan is completed during the Design phase of the Solution Delivery Life Cycle.
      It should be updated anytime additional information or project changes affect its content.
 It is a required deliverable on Large and Medium projects, and a best practice on Fast Track projects.
For additional guidance, the Project Classification Worksheet is available.

This template is provided as a guideline to follow in producing the minimum basic information needed
to successfully complete a Project QA/Test Plan.

Project Managers are empowered to use this template as needed to address any specific requirements of
the proposed project at hand.  The amount of detail included in the template will depend on the size and
complexity of the project.