ISTQB Foundation Level: Chapter 5, Test Management

ISTQB Foundation Level
Chapter 5, Test Management

Agenda
 Test Organization
 Test Planning & Estimation
 Test Progress Monitoring & Control
 Configuration Management
 Risk & Testing
 Incident Management
ISTQB | Test Management

All work described was performed by Capgemini or a Capgemini affiliate
© 2007 Capgemini - All rights reserved 1
Test Organization: Independent Testing
 Independent testing improves effectiveness of finding defects.

 Increases customer's confidence when the system has been
tested by people who have completely understood the business
flow apart from the software development team's view.
Independent testing team is formed by :
 Independent testers within development teams.
 Independent testers from the business community.
 Independent test team within an organization reporting to
project management.
 Independent test specialists for special kind of testing like
usability testing, security testing.
 Independent testers external to an organization.
Continued…

Test Organization: Independent Testing
Benefits of independent testing:

 Independent testers see defects which others cannot detect and
independent testers are unbiased.
 Software specifications and requirements are validated and
verified while the software is getting designed or developed.
 It creates a healthy competition amongst the application
developers and test team that leads to the superior and robust
software as an outcome.
Drawbacks of independent testing:
 Isolation from the development team (if totally independent).
 Developers might lose sense of responsibility for quality.

Test Organization: Tasks of Test Leader & Tester
Typical test leader tasks may include:
 Co-ordinate/Write the test strategy & test plan for the project
along with the consent of the project manager.
 Plan the tests considering the impact of potential risks. Planning
may also include selecting test approaches, time/cost/effort
estimation, acquiring resources, identifying training needs for
those resource.
 Initiate the specification, preparation, implementation & execution
of tests. Monitor & control the execution.
 Initiate necessary corrective actions based on test execution
progress reports.
 Facilitate & organize implementation of test environment.
 Scheduling & tracking of tests.
 Introduce suitable metrics to evaluate quality of testing and
overall product.

Test Organization: Tasks of Test Leader & Tester
Typical tester tasks may include:

 Analyze, review & assess user requirements from testing
perspective.
 Discuss doubts/queries with Development Team / Client.
 Designing / implementing at all levels.
 Setting up the test environment.
 Preparing / acquiring test data.
 Executing and logging test results.
 Documenting deviations observed during testing and comparing
them with expected results.
 Result capturing and analysis.
 Defects and status reporting.

Test Planning & Estimation: Test Planning
 Test planning is influenced by the test policy of an organization, the

scope of testing, objectives, risks, constraints, criticality, testability
and the availability of resources.
 Test planning is a continuous activity & is performed throughout all
project processes & activities.
 Defining the test strategy, including definition of all test levels,
entry/exit criteria
 Critical decisions like what to test, defining roles to be performed,
when & how the testing activities should take place, how to evaluate
the test results & most importantly when to stop testing (exit criteria)
 Selecting metrics for monitoring test preparation & execution, defect
resolutions & risks.
 Feedback gathered from test activities is used to recognize
changing risks & enhance the planning accordingly

Test Planning & Estimation: Test Plan - IEEE Test Plan Template
 Test plan identifier

 References
 Introduction
 Test items
 Software Risk issues
 Features to be tested
 Features not to be tested
 Approach
 Item Pass/Fail criteria
 Suspension criteria and resumption requirements

Test Planning & Estimation: Test Plan - IEEE Test Plan Template
 Test deliverables
 Testing tasks
 Environmental needs
 Responsibilities
 Staffing and training needs
 Schedule
 Risks and contingencies
 Approvals
 Glossary

Test Planning & Estimation: Test Estimation
Two commonly used approaches for estimation:

 Estimating the testing efforts based on metrics of former or similar
projects
 Estimating of the tasks by the owner of the tasks or by experts
Test effort will depend on the following factors:
 Characteristics of the product under test: Quality of the
specification, size & complexity of the product, scope of testing
(testing levels etc)
 Characteristics of the development process: Tools used, test
process, skills of people involved, time pressure
 The outcome of testing: No of defects found & amount of rework
coming of out of it

Test Planning & Estimation: Test Approaches
Test Approaches (Strategies) can be adopted in two ways:

 Preventive approach: Tests are designed as early as possible.
 Reactive approach: Test Design starts after the software system has been
produced.
Other popular ways of test approaches may include:
 Analytical approach: Analyzing risk areas of the project & focusing the
testing on those areas.
 Model based approach: Testing using statistical info about failure rates or
usage.
 Methodical approach: Failure based, checklist based, quality
characteristic based.
 Process based approach: Driven by industry specific standards or
standard methodologies.
 Consultative approach: Test coverage is driven by the advice of industry
experts / business domain experts outside the test team.

Test Progress Monitoring & Control: Test Monitoring
 Test progress monitoring is the process in which various test

activities are assessed & compared against their planned goals.
Metrics can be used to measure progress of various activities.
 Percentage of work done in test case preparation.
 Percentage of work done in test environment preparation.
 Test case execution (e.g. no of test cases run/not run, test cases
passed/failed).
 Defect Info (Defects found/fixed, failure rate, retest progress).
 Test coverage in terms of requirements, code, risks.
 Date comparison against set milestones.

Test Progress Monitoring & Control: Test Monitoring
Defects Raised - New Test Case Format Vs Old Test Case Format
Test defect density
No. of test defects per test case

20
18 0.08
16 0.07
No. of defects
14 0.06
12 0.05
10 0.04
8 0.03
6 0.02
4
0.01
2
0.00
0
te
el
TS
S
EB
y
S
ay
TS
W
PS
te
lic
el
EB
eb
UP
PS
ay
uo
l ic
ED
PS
ep
eb
EM
uo
ED
Po
EM
U
ep
Po
Si
eQ
Si
eQ
y/
y/
pa
pa
to
to
New TC Format
Au
Au
Old TC Format
Application Nam e Application Name

Test Progress Monitoring & Control: Test Reporting and Control
Test reporting summarizes information about the following:

 Testing progress in terms of test case execution, defects opened,
defects fixed, no retests occurred etc.
 Analyzed information & metrics to support recommendations &
decisions for future actions such unfixed defects & their impact on
the project, outstanding risks, level confidence in the quality of
software.
 Test control is guiding or corrective actions taken as a result of
information & metrics gathered/reported.
Examples of test control:
 Re-prioritizing of tests if any risk becomes an issue.
 Changing test schedule based on test environment availability.

Configuration Management
 Configuration management is responsible for the management of all

product-related specifications and ensure structured handling of all
development/testing process work results.
 Configuration management (CM) is the detailed recording and
updating of information that describes an enterprise's computer
systems and networks, including all hardware and software
components.
CM for testing can be useful in ensuring that:
 All items of test ware are identified, version controlled, tracked for
changes so that traceability is maintained throughout the testing
process.
 All identified documents & items can be referenced unambiguously
in the test documentation.
 Configuration management procedures & tools are chosen,
documented & implemented in the test planning process itself.
Risks & Testing
What is Risk ?
Risk
Damage Probability of failure
Lack of quality
Risk = You don’t know what will happen but you do know the probabilities
Uncertainty = You don’t even know the probabilities.
 Risk can be defined as the chance that an event, hazard, threat or
situation occurs along with it’s undesirable consequences &
potential problems.
 Risk-based testing (RBT) is a type of software testing that prioritizes
the features and functions to be tested based on priority/importance
and likelihood or impact of failure.

Risks & Testing: Risk Analysis and Testing
Test Plan
Test Item Tree Risk

Strategy
Risk
Identification
Testing,
Risk Inspection etc.
Assessment
Risk
Matrix: Cost Mitigation Test Metrics
and Probability
Risk
Reporting
Risk
Prediction

Risks & Testing : Project Risks
Projects risks can be those risks which hamper the project’s ability to
deliver it’s objectives.
Examples of Project Risks:
 Supplier issues such as failure of third party or vendor.
 Organizational issues such as skill & staff shortages,
personal/training issues
 Political issues such as communication between testers &
development team, failure to follow up on information found in
testing & reviews.
 Technical issues such as improper requirements, technology
constraints in meeting the requirements, quality of design, code,
tests.

Risks & Testing : Product Risks
Potential failure areas in software system itself are called as product

risks since they affect quality of the product.
Examples of product risk are:

 Complex features affecting multiple areas of the existing product,
like an upgrade/migration of the system.
 New Technologies used in the product; for example a new DB
server, a new programming language, a new integration, etc.
 New Developers or Development Teams, who may lack experience
and thus pose a higher risk to the existing product.
 Tight Schedules, that make people work in a rush and commit more
mistakes.

Incident/Defect Management
 Discrepancies between expected & actual defects should be logged

as incidents/defects.
 A good Incident/defect management process helps to gather and
manage information during each defect workflow i.e. from initial
discovery to final resolution or deferral.
 Incidents/defects may be raised during development, review, testing
or use of software product.
 Incidents/defects can be issues in code, in working system, in
software specification documentation, help documents.
 Incident reports are generated to provide developers & other
concerned partied a notification about the problem.

Incident/Defect Management : Defects categorization
Following are the parameters generally used in categorization of a defect.

 Defect Severity
 Defect Priority
Defect Severity
A severity classification of a software error is based on the degree of the
impact on the system under test.
 Fatal : This could cause serious failure in the system.

 Major : Defect that would result in failure of the software element(s) or
an observable deviation from specs.
 Minor : Defect that would affect only the non-functional aspects of the
software elements.
Continued …

Incident/Defect Management : Defects categorization
Defect Priority
Priority is based on the importance and urgency of resolving the defect.
 Immediate : The bug should be resolved immediately.
 High : This bug should be resolved as soon as possible in the
normal course of development activity, before the software is
released.
 Medium : This bug should be repaired after serious Defects have
been fixed.
 Low : It can be resolved in a future major system revision or not be
resolved at all

Incident/Defect Management - Defect Status Flow
Tester identifies an incident
Incident is Reviewed/Investigated
Tester closes the

Enhancement Invalid
A Incident
acknowledged Incident
Defect/Incident
(status is Closed)
Valid
Incident
Defect is assigned to B
B
Developer
Developer fixes
Defect Y
(status is Fixed) e
s
Tester assigns
Developer assigns Tester tests Fixe No Defect back to
Fix Defect back to the Bug Fix d Developer
Tester (step known as Retesting) (status is Reopen)
(status is Reopened)

Incident/Defect Management - Defect Status Flow - Enhancement
A
Enhancement
Business reviews
Enhancement
Valid
Enhancement
Agreed to B
change
Deferred
Enhancement is kept in
Open Forwarded status

Incident/Defect Management - Defect Log

Incident/Defect Management - Defect Log (Cont..)

Q&A

Thank You
www.capgemini.com

ISTQB Foundation Level: Chapter 5, Test Management

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ISTQB Foundation Level: Chapter 5, Test Management

Загружено:

Авторское право:

Доступные форматы

ISTQB Foundation Level

Chapter 5, Test Management

ISTQB | Test Management

 Independent testing improves effectiveness of finding defects.

ISTQB | Test Management

Benefits of independent testing:

ISTQB | Test Management

ISTQB | Test Management

Typical tester tasks may include:

ISTQB | Test Management

 Test planning is influenced by the test policy of an organization, the

ISTQB | Test Management

 Test plan identifier

 Features not to be tested

 Suspension criteria and resumption requirements

ISTQB | Test Management

 Staffing and training needs

 Risks and contingencies

ISTQB | Test Management

Two commonly used approaches for estimation:

ISTQB | Test Management

Test Approaches (Strategies) can be adopted in two ways:

ISTQB | Test Management

 Test progress monitoring is the process in which various test

ISTQB | Test Management

No. of test defects per test case

ISTQB | Test Management

Test reporting summarizes information about the following:

ISTQB | Test Management

 Configuration management is responsible for the management of all

Damage Probability of failure

ISTQB | Test Management

Test Item Tree Risk

ISTQB | Test Management

ISTQB | Test Management

Potential failure areas in software system itself are called as product

Examples of product risk are:

ISTQB | Test Management

 Discrepancies between expected & actual defects should be logged

ISTQB | Test Management

Following are the parameters generally used in categorization of a defect.

 Fatal : This could cause serious failure in the system.

ISTQB | Test Management

ISTQB | Test Management

Tester closes the

ISTQB | Test Management

ISTQB | Test Management

ISTQB | Test Management

ISTQB | Test Management

ISTQB | Test Management

Вам также может понравиться