ISTQB CTFL - Chapter 05

1. CHAPTER 5 -
Test management
Based on ISTQB CTFL Syllabus
Presented by :
DavisThomas K

2. Syllabus

3. After completing
this lesson, you
will be able to
understand:
 1 Recognize the importance of independent
testing. (Kl)
 2 List the benefits and drawbacks of
independent testing within an organization.
(K2)
 3 Recognize the different team members to be
considered for the creation of a test team. (Kl)
 4 Recall the tasks of typical test leaders and
testers. (Kl)

4. K Levels
5)Test Management: (K3)
 Test organization (K2)
 Test Plans, estimates and strategies (K3)
 Test progress, monitoring and control (K2)
 Configuration management (K2)
 Risk and testing (K2)
 Incident management (K3)

5. Roles and
responsibilities
of aTest Leader?
Initiation , Planning, Execution,
Monitoring and Controlling , Closing
phase
devise the test objectives, organizational
test policies, test strategies and test
plans.
Automation – Analysis

6. Roles and
responsibilities
of a Tester ?
Test case preparation
Requirement analysis
Testers execute and log the tests, evaluate
the results and document problems found.
They monitor the testing and the test
environment, often using tools for this task,
and often gather performance metrics.
Throughout the testing life cycle, they
review each other’s work, including test
specifications, defect reports and test
results.

7. WhatTest plan
does ?
 Test plan is the project plan for the testing work to be
done. It is not a test design specification, a collection
of test cases or a set of test procedures
 First, by writing a test plan it guides our thinking.
 Second, the test planning process and the plan itself
serve as the means of communication with other
members of the project team, testers, peers, managers
and other stakeholders.
 Third, the test plan helps us to manage change.

8. Test plan
template

9. Estimating
testing
testing is a process rather than a single
activity.
We need to break down the activities

10. Fundamental
test process
(Revise)
 What is in scope and what is out of scope for this testing effort?
What are the test objectives?
What are the important project and product risks?
What constraints affect testing (e.g., budget limitations, hard
deadlines, etc.)?
What is most critical for this product and project?
Which aspects of the product are more (or less) testable?
What should be the overall test execution schedule and how
should we decide the order in which to run specific tests?

11. Estimation
techniques
1. People with expertise on the tasks to
be done:
 [WBS,Bottom-up, tool : MS Project]
2. Consulting the people who will do the
work
[team's wisdom to create theWBS]

12. Factors
affecting test
effort
 Project Documentation
 Increase in Software Application Size
 Software Life Cycle
 Maturity of Process
 Time Constraints
 Availability of Skilled Testers
 Test Results

13. Test
approaches or
Test strategy
 one of the most powerful factor in the success of the test effort
and the accuracy of the test plans and estimates.
 Analytical [The risk-based strategy /requirement based strategy]
 Model-based [You can build mathematical models for loading and
response for e commerce servers, and test based on that model]
 Methodical [You might have a checklist that you have put
together over the years that suggests the major areas of testing to
run ]
 Process – or standard-compliant [Process- or standard-compliant
strategies have in common reliance upon an externally developed
approach to testing]
 Dynamic [Dynamic strategies, such as exploratory testing]
 Regression-averse [Automated regression suite]

14. Test
monitoring
 Provide the project team with visibility about the test results.
 Measure the status of the testing, test coverage and test items
against the exit criteria to determine whether the test work is
done.
 Gather data for use in estimating future test efforts.

15. Test control
 Test control is about guiding and corrective actions to try to
achieve the best possible outcome for the project.
 how test control affect testing ?
 Example : A portion of the software under test will be delivered
late but market conditions dictate that we cannot change the
release date. At this point of time test control might involve re-
prioritizing the tests so that we start testing against what is
available now.

16. Configuration
management
 Configuration management is about making sure that these items
[source code, test scripts, third-party software, hardware, data
and both development and test documentation.] are managed
carefully, thoroughly and attentively during the entire project and
product life cycle.
 Ideally, when testers receive an organized, version-controlled test
release from a change-managed source code repository, it is along
with a test item trans-mittal report or release notes.

17. Risk in
software
testing?
 In the future, a risk has some probability between 0%
and 100%; it is a possibility, not a certainty.
 We can classify risks into following categories:
 Product risk (factors relating to what is produced by
the work, i.e. the thing we are testing).
 Project risk (factors relating to the way the work is
carried out, i.e. the test project)


18. What is
Product Risk
 Product risk is the risk associated with the software or system, the
possibility that software or system may fail to satisfy end
user/customers expectations is known as product risk.
 If the software skips some key function that the customers
specified, the users required or the stakeholders were promised.
 If the software is unreliable and frequently fails to work.
 If software fail in ways that cause financial or other damage to a
user or the company that user works for.
 If the software has problems related to a particular quality
characteristic, which might not be functionality, but rather
security, reliability, usability, maintainability or performance.

19. What is Project
Risk in testing?
Risks associated with the testing activity which can endanger the
test project cycle is known as project risk.
Some of the risks associated with project are:
1. Delay in the test build to test team.
2. Unavailability of test environment.
3. Delay in fixing test environment due to lack of system admin.
4. Delay in fixing defects by development team.
5.Organizational problems which can be like shortage of staff.
Required skills etc.
6. Major changes in the SRS which invalidates the test cases and
requires changes in the test case.
In order to deal with project risks we need to apply concepts like
identifying, prioritizing and managing the project risks.

20. Actions to be
taken on Risk.
 For any risk, project risk or product risk we have four typical
actions that we can take:
 Mitigate:Take steps in advance to reduce the possibility and
impact of the risk.
 Contingency: Have a plan in place to reduce the possibility of the
risk to become an outcome.
 Transfer: Convince some other member of the team or project
stakeholder to reduce the probability or accept the impact of the
risk.
 Ignore: Ignore the risk, which is usually a good option only when
there is little that can be done or when the possibility and impact
of that risk are low in the project.

21. Risk based
testing
 Risk is the probability of occurrence of an undesirable outcome.
This outcome is also associated with an impact. Since there might
not be sufficient time to test all functionality, Risk based testing
involves testing the functionality which has the highest impact
and probability of failure.
 Risk-based testing starts early in the project
 Risk-based testing also involves measuring how well we are doing
at finding and removing defects in critical areas.

22. How to
perform risk
based testing?
 Make a prioritized list of risks.
 Perform testing that explores each risk.
 As risks evaporate and new ones emerge, adjust your
test effort to stay focused on the current crop.

23. What is Risk
analysis?
 One technique for risk analysis is a close reading of the
requirements specification, design specifications, user
documentation and other items.
 Another technique is brainstorming with many of the project
stakeholders.

24. What is an
Incident in
software
testing?
 While executing a test, you might observe that the actual results
vary from expected results.When the actual result is different
from the expected result then it is called as incidents, bugs,
defects, problems or issues.
 An incident is basically any situation where the system exhibits
questionable behavior
[not necessarily a true defect]
It will be a good idea to log, report, track, and manage incidents
found during development and reviews because it gives useful
information about the early and cheaper defect detection and
removal activities.

25. Test Report

26. Q &A
Lets try to answer few questions based
on chapter 05

27. Question 1 Why is independent testing important?
a. Independent testing is usually cheaper than testing your
own work.
b. Independent testing is more effective at finding defects.
c. Independent testers should determine the processes and
methodologies used.
d. Independent testers are dispassionate about whether the
project succeeds or fails.

28. Question 2 Which of the following is among the typical tasks
of a test leader?
a. Develop system requirements, design specifications and
usage models.
b. Handle all test automation duties.
c. Keep tests and test coverage hidden from programmers.
d. Gather and report test progress metrics.

29. Question 3 According to the ISTQB Glossary, what do we
mean when we call someone a test manager?
a. A test manager manages a collection of test leaders.
b. A test manager is the leader of a test team or teams.
c. A test manager gets paid more than a test leader.
d. A test manager reports to a test leader.

30. Question 4 What is the primary difference between the test plan, the test design
specification, and the test procedure specification?
a. The test plan describes one or more levels of testing, the test design specification
identifies the associated high-level test cases and a test procedure specification describes
the actions for executing a test.
b. The test plan is for managers, the test design specification is for programmers and the
test procedure specification is for testers who are automating tests.
c. The test plan is the least thorough, the test procedure specification is the most thorough
and the test design specification is midway between the two.
d. The test plan is finished in the first third of the project, the test design specification is
finished in the middle third of the project and the test procedure specification is finished in
the last third of the project

31. Question 4 Which of the following factors is an influence on the test effort
involved in most projects?
a. Geographical separation of tester and programmers.
b. The departure of the test manager during the project.
c. The quality of the information used to develop the tests.
d. Unexpected long-term illness by a member of the project team.