Quality Assurance Plan

The quality assurance plan consists of the time estimates for the following but not limited to the
below mentioned
1) Analysis and Review of BRD, FSD, etc
2) Test Plan creation
3) Test cases creation
4) Test cases execution
5) Bug Verification
6) Regression cycle
7) Browser Compatibility and devices testing
8) Final Post release test execution

THE TEST PLAN
The test plan is a mandatory document. You cant test without one. For simple, straight-forward
projects the plan doesnt have to be elaborate but it must address certain items as the following
components should be covered in a software test plan.

Items Covered by a Test Plan
Component
Description Purpose
Responsibilities
Specific people who are
and their assignments
Assigns responsibilities and keeps
everyone on track and focused
Assumptions
Code and systems status
and availability
Avoids misunderstandings about
schedules
Test
Testing scope, schedule,
duration, and
prioritization
Outlines the entire process and
maps specific tests
Communication
Communications plan
who, what, when, how
Everyone knows what they need
to know when they need to know
it
Risk Analysis
Critical items that will be
tested
Provides focus by identifying
areas that are critical for success
Defect Reporting
How defects will be
logged and documented
Tells how to document a defect so
that it can be reproduced, fixed,
and retested
Environment
The technical
environment, data, work
area, and interfaces used
in testing
Reduces or eliminates
misunderstandings and sources of



Test Plan Terminology
Term Description
Test Plan
A formal detailed document that describes
Scope, objectives, and the approach to testing,
People and equipment dedicated/allocated to
testing
Tools that will be used
Dependencies and risks
Categories of defects
Test entry and exit criteria
Measurements to be captured
Reporting and communication processes
Schedules and milestones
Test Case
A document that defines a test item and specifies a
set of test inputs or data, execution conditions, and
expected results. The inputs/data used by a test case
should be both normal and intended to produce a
good result and intentionally erroneous and
intended to produce an error. A test case is
generally executed manually but many test cases
can be combined for automated execution.
Test Script
Step-by-step procedures for using a test case to test
a specific unit of code, function, or capability
Test Scenario
A chronological record of the details of the
execution of a test script. Captures the
specifications, tester activities, and outcomes. Used
to identify defects.
Test Run
A series of logically related groups of test cases or
conditions

Unit Testing & System Testing:
Unit Testing:
Unit tests are basically short and specific to test that the code actually does what it should do. A
series of stand-alone tests are conducted during Unit Testing. Each test examines an individual
component that is new or has been modified. A unit test is also called a module test because it
tests the individual units of code that comprise the application.
Each test validates a single module that, based on the technical design documents, was built to
perform a certain task with the expectation that it will behave in a specific way or produce
specific results. Unit tests focus on functionality and reliability, and the entry and exit criteria
can be the same for each module or specific to a particular module. Unit testing is done in a test
environment prior to system integration. If a defect is discovered during a unit test, the severity
of the defect will dictate whether or not it will be fixed before the module is approved.
System Testing:
System Testing tests all components and modules that are new, changed, affected by a change, or
needed to form the complete application. The system test may require involvement of other
systems but this should be minimized as much as possible to reduce the risk of externally-
induced problems. Testing the interaction with other parts of the complete system comes in
Integration Testing. The emphasis in system testing is validating and verifying the functional
design specification and seeing how all the modules work together. For example, the system test
for a new web interface that collects user input for addition to a database doesnt need to include
the databases ETL application, processing can stop when the data is moved to the data staging
area if there is one.
The first system test is often a smoke test. This is an informal quick-and-dirty run through of the
applications major functions without bothering with details. The term comes from the hardware
testing practice of turning on a new piece of equipment for the first time and considering it a
success if it doesnt start smoking or burst into flame. System testing requires many test runs
because it entails feature by feature validation of behavior using a wide range of both normal and
erroneous test inputs and data. When an error or defect is discovered, previously executed system
tests must be rerun after the repair is made to make sure that the modifications didnt cause other
problems.
Integration Testing:
Integration testing examines all the components and modules that are new, changed, affected by
a change, or needed to form a complete system. Where system testing tries to minimize outside
factors, integration testing requires involvement of other systems and interfaces with other
applications, including those owned by an outside vendor, external partners, or the customer. For
example, integration testing for a new web interface that collects user input for addition to a
database must include the databases ETL application even if the database is hosted by a
vendorthe complete system must be tested end-to-end. In this example, integration testing
doesnt stop with the database load; test reads must verify that it was correctly loaded.
Integration testing also differs from system testing in that when a defect is discovered, not all
previously executed tests have to be rerun after the repair is made. Only those tests with a
connection to the defect must be rerun, but retesting must start at the point of repair if it is before
the point of failure.
Integration testing has a number of sub-types of tests that may or may not be used, depending on
the application being tested or expected usage patterns.
Compatibility Testing Compatibility tests insures that the application works with
differently configured systems based on what the users have or may have. When testing a
web interface, this means testing for compatibility with different browsers and connection
speeds.

Performance Testing Performance tests are used to evaluate and understand the
applications scalability when, for example, more users are added or the volume of data
increases. This is particularly important for identifying bottlenecks in high usage
applications. The basic approach is to collect timings of the critical business processes while
the test system is under a very low load (a quiet box condition) and then collect the same
timings with progressively higher loads until the maximum required load is reached. For
data retrieval application, reviewing the performance pattern may show that a change needs
to be made in a stored SQL procedure or that an index should be added to the database
design.

Stress Testing Stress Testing is performance testing at higher than normal simulated loads.
Stressing runs the system or application beyond the limits of its specified requirements to
determine the load under which it fails and how it fails. A gradual performance slow-down
leading to a non-catastrophic system halt is the desired result, but if the system will
suddenly crash and burn its important to know the point where that will happen.
Catastrophic failure in production means beepers going off, people coming in after hours,
system restarts, frayed tempers, and possible financial losses. This test is arguably the most
important test for mission-critical systems.

Load Testing Load tests are the opposite of stress tests. They test the capability of the
application to function properly under expected normal production conditions and measure
the response times for critical transactions or processes to determine if they are within limits
specified in the business requirements and design documents or that they meet Service
Level Agreements. For database applications, load testing must be executed on a current
production-size database. If some database tables are forecast to grow much larger in the
foreseeable future then serious consideration should be given to testing against a database of
the projected size.

User Acceptance Testing:
User Acceptance Testing is also called Beta testing, application testing, and end-user testing.
Whatever you choose to call it, its where testing moves from the hands of the IT department into
those of the business users. Software vendors often make extensive use of Beta testing, some
more formally than others, because they can get users to do it for free.
By the time UAT is ready to start, the IT staff has resolved in one way or another all the defects
they identified. Regardless of their best efforts, though, they probably dont find all the flaws in
the application. A general rule of thumb is that no matter how bulletproof an application seems
when it goes into UAT, a user somewhere can still find a sequence of commands that will
produce an error.
A phase of UAT called Unstructured Testing will be conducted whether or not its in the Test
Plan. Also known as guerilla testing, this is when business users bash away at the keyboard to
find the weakest parts of the application. In effect, they try to break it. Although its a free-form
test, its important that users who participate understand that they have to be able to reproduce
the steps that led to any errors they find. Otherwise its of no use. This testing insures that the
application is tested in real-world situations and that the tests cover the full range of business
usage. The goal of UAT is to simulate realistic business activity and processes in the test
environment.
Mobile Application Testing
Mobile application testing is a process by which application software developed for hand held
mobile devices is tested for its functionality, usability and consistency on various mobile
operating systems and versions. There are different types of testing performed on the
applications on mobile devices some of them are as follows:
1) Functionality testing
2) Performance testing
3) Responsiveness testing
4) Usability testing
5) Laboratory testing
6) Interrupt testing