test management

test management: The process of planning, estimating,

monitoring and control of test
activities, typically carried out by a test manager.

Introduction
Test managementmost commonly refers to the activity of
managing the computer software testing process.
A test management tool issoftwareused to managetests
(automated or manual) that have been previously
specified by a test procedure.
It is often associated withautomationsoftware. Test
management tools often includerequirementand/or
specificationmanagement modules that allow automatic
generation of therequirement test matrix(RTM), which is
one of the main metrics to indicate functional coverage of
asystem under test(SUT).

Test documentation:
Test Plan

Testing documentation involves the documentation of artifacts which should be developed before or during the testing of
Software.

Documentation for Software testing helps in estimating the testing effort required, test coverage, requirement tracking/tracing
etc. This section includes the description of some commonly used documented artifacts related to Software testing such as:

Test Plan

Test Scenario

Test Case

Traceability Matrix

Test Plan

A test plan outlines the strategy that will be used to test an application, the resources that will be used, the test environment in
which testing will be performed, the limitations of the testing and the schedule of testing activities. Typically the Quality
Assurance Team Lead will be responsible for writing a Test Plan.

A test plan will include the following.

Introduction to the Test Plan document

Assumptions when testing the application

List of test cases included in Testing the application

List of features to be tested

What sort of Approach to use when testing the software

List of Deliverables that need to be tested

The resources allocated for testing the application

Any Risks involved during the testing process

A Schedule of tasks and milestones as testing is started

test plan: A document describing the scope, approach, resources, and

schedule of intended test activities. It identifies amongst others test
items, the
features to be tested, the testing tasks, who will do each task, degree
of tester
independence, the test environment, the test design techniques and
entry
and exit criteria to be used (and the rationale for their choice), and
any risks
requiring contingency planning. It is a record of the test planning
process.

 Test Scenario
A one line statement that tells what area in the application will be
tested. Test Scenarios are used to ensure that all process flows
are tested from end to end. A particular area of an application
can have as little as one test scenario to a few hundred scenarios
depending on the magnitude and complexity of the application.
The term test scenario and test cases are used interchangeably
however the main difference being that test scenarios has
several steps however test cases have a single step. When
viewed from this perspective test scenarios are test cases, but
they include several test cases and the sequence that they
should be executed. Apart from this, each test is dependent on
the output from the previous test.

Test Case

Test cases involve the set of steps, conditions and inputs which can be used while performing the testing tasks. The main
intent of this activity is to ensure whether the Software Passes or Fails in terms of its functionality and other aspects. There
are many types of test cases like: functional, negative, error, logical test cases, physical test cases, UI test cases etc.

Furthermore test cases are written to keep track of testing coverage of Software. Generally, there is no formal template which
is used during the test case writing. However, following are the main components which are always available and included
in every test case:

Test case ID.

Product Module.

Product version.

Revision history.

Purpose

Assumptions

Pre-Conditions.

Steps.

Expected Outcome.

Actual Outcome.

Post Conditions.

Many Test cases can be derived from a single test scenario. In addition to this, some time it happened that multiple test cases
are written for single Software which is collectively known as test suites.

Test plan documentation templates:

test estimation: The calculated approximation of a
result related to variousaspects of testing (e.g., effort
spent, completion date, costs involved, number of test
cases, etc.) which is usable even if input data may be
incomplete, uncertain,or noisy.
test schedule: A list of activities, tasks, or events of
the test process, identifying their intended start and
finish dates and/or times and interdependencies.

Test monitoring, reporting and

control
Test Monitoring
The purpose of test monitoring is to give feedback and
visibility about test activities. Information to be
monitored may be collected manually or automatically
and may be used to measure exit criteria, such as
coverage. Metrics may also be used to assess progress
against the planned schedule and budget.

 Test Reporting
Test reporting is concerned with summarizing
information about the testing endeavour, including:
What happened during a period of testing, such as
dates when exit criteria were met.
Analysed information and metrics to support
recommendations and decisions about future actions,
such as an assessment of defects remaining, the
economic benefit of continued testing, outstanding
risks, and the level of confidence in tested software.

 Test control
Test control describes any guiding or corrective actions taken as
a result of information and metrics gathered and reported.
Actions may cover any test activity and may affect any other
software life cycle activity or task.
Examples of test control actions are:
Making decisions based on information from test monitoring.
Re-prioritize tests when an identified risk occurs (e.g. software
delivered late).
Change the test schedule due to availability of a test environment.
Set an entry criterion requiring fixes to have been retested
(confirmation tested) by a developer before accepting them into
a build.

Risk based testing

risk: A factor that could result in future negative consequences; usually

expressed as impact and likelihood.
risk type: A set of risks grouped by one or more common factors such as a
quality attribute, cause, location, or potential effect of risk. A specific set of
product risk types is related to the type of testing that can mitigate (control)
that risk type. For example, the risk of user interactions being misunderstood
can be mitigated by usability testing.
product risk: A risk directly related to the test object. See also risk. [Note: We
will also use the commonly used synonym quality risk in this book.]
project risk: A risk related to management and control of the (test) project,
e.g., lack of staffing, strict deadlines, changing requirements, etc. See also risk.
risk-based testing: An approach to testing to reduce the level of product risks
and inform stakeholders of their status, starting in the initial stages of a
project. It involves the identification of product risks and the use of risk levels
to guide the test process.

Risk Management
Risk management includes three primary activities:
Risk identification, figuring out what the different project and
quality risks
are for the project
Risk analysis, assessing the level of risktypically based on
likelihood and
impactfor each identified risk item
Risk mitigation, which is really more properly called risk control
because
it consists of mitigation, contingency, transference, and acceptance
actions
for various risks

Risk Management
risk management: Systematic application of procedures and practices
to the
tasks of identifying, analyzing, prioritizing, and controlling risk.
risk identification: The process of identifying risks using techniques
such as
brainstorming, checklists, and failure history.
risk analysis: The process of assessing identified risks to estimate
their impact
and probability of occurrence (likelihood).
risk mitigation or risk control: The process through which decisions
are
reached and protective measures are implemented for reducing risks to,
or
maintaining risks within, specified levels.

Risk-Based Testing throughout

the Lifecycle
During test planning, risk management comes first. We perform a quality risk analysis
early in the project, ideally once the first draft of a requirements specification is
available. From that quality risk analysis, we build an estimate for negotiation with
and, we hope, approval by project stakeholders and management.
During test control, we will periodically adjust the risk analysis throughout the project.
That can lead to adding, increasing, or decreasing test coverage; removing,
delaying, or accelerating the priority of tests; and other such activities.
During test analysis and design, we work with the test team to allocate test
development and execution effort based on risk. Because we want to report test
results in terms of risk, we maintain traceability to the quality risks.
During implementation and execution, we sequence the procedures based on the
level of risk. We ensure that the test team, including the test analysts and technical
test analysts, uses exploratory testing and other reactive techniques to detect
unanticipated high-risk areas.
During the evaluation of exit criteria and reporting, we work with our test team to
measure test coverage against risk. When reporting test results (and thus release
readiness), we talk not only in terms of test cases run and bugs found, but also in
terms of residual risk.