ISTQB Certified Tester

Foundation Level

• Module 1 of 6 : Fundamentals of Testing

February, 2017
Introduction (1/5) : About the ISTQB

International Software Testing Qualifications Board (ISTQB)

• Non-profit organization with voluntary contributions to syllabi and exams from

Testing experts across the globe
• 47 national Testing Boards
▪ Including the <Indian Board>
• More than 145,000 certified Testers across the world
▪ Over 9,000 Foundation Level certified in <INDIA>
• ZenQ is an affiliate member of Indian Testing Board.

ISTQB Vision:

“Enabling Test Professionals, through Globally accepted Software Testing Certification

standards to support their career development, built on solid professional foundations and
exemplary organizational culture. ”

2
 Introduction(2/5) : Benefits of ISTQB Certification

• Internationally recognized qualification

• Becoming the standard for Testing Professionals

• Promotes a common language for testers

• Promotes consistent and good testing practices

• Enables professionally qualified testers to be recognized

• Provides a framework for the development of tester’ careers

3
Introduction (3/5) : ISTQB Framework

4
Introduction(5/5) : Study Sessions

These study packs are intended as sessions directly from the chapters in the syllabus

There are 6 main modules

1. Fundamentals of Testing
2. Testing Throughout the Software Life Cycle
3. Static Techniques
4. Test Design Techniques
5. Test Management
6. Tool Support for Testing

5
Module 1of 6

FUNDAMENTALS OF TESTING

6
Covered in this lesson...

1.1 Why is Testing Necessary?

1.2 What is Testing?
1.3 The 7 Testing Principles
1.4 The Fundamental Test Process
1.5 The Psychology of Testing
1.6 The Code of Ethics

7
 Topic 1.1

WHY IS TESTING NECESSARY?

8
Software Systems(1/4)

Software is an integral part of life

▪ Business applications (eg. banking, factory machines)

▪ Consumer products (eg. cars, washing machines)

Software is everywhere!
What bugs
Example where software didn’t work correctly… have you
found?
In 2010 the Toyota Prius was dogged by software
bugs that caused uneven braking in the car’s antilock
brake system (ABS). Toyota had to recall nearly half a
million of these hybrid cars.

9
 Software Systems(2/4)
What are some of the consequences of faulty software?

Loss of Injury or Loss of

Loss of Money Loss of Time
Reputation Life

Example :
Example : Example :
Brand was Example:
A company A defect
damaged by
gets sued caused a Malfunction
ongoing
because an delay in a call of switching
performance
advertised center, so in a railway
business issues of a
that not as line caused
listing didn’t major airline,
many calls trains to
display so customers
could be collide
correctly went
answered
elsewhere

10
Software Systems (3/4): Causes of Software Defects

A human makes a If executed, may

mistake (error) cause a failure

Which produces a
defect (fault, flaw
or bug) in code or
document

11
Software Systems(4/4) : Root cause

• Humans are fallible

• Time pressure

• Complexity – code, infrastructure, many system interactions

• Changing technologies

• Environmental conditions – radiation, pollution, magnetism

12
 Role of Testing

• Testing of systems and documentation can help reduce the risk of problems and contribute
to quality – if defects are found and corrected before the system is released for operational
use.

• Testing may be required for contractual, legal or industry-specific standards

▪ Eg. Sarbanes-Oxley Act (SoX) requires compliance for governance, accounting and
reporting standards for companies trading with US companies.

• Testing can give confidence in the quality of the software

13
Quality Assurance

• Testing is only one part of Quality Assurance!

• Other Quality Assurance activities should occur in the

organization

▪ Requirements and documentation

▪ Development standards
▪ Training
▪ Defect analysis
▪ Lessons learnt can help contribute

14
How much testing is enough?

Level of
Technical
Level of Risk
Business
Risk

Project
Constraints

How much testing is enough?

Sufficient information to stakeholders to make informed
decisions

15
 Topic 1.2

WHAT IS TESTING ?

16
What is Testing? (1/3)
• Testing isn’t just execution

• Test activities exist before and after test execution

▪ Planning and control

▪ Static testing and reviewing of documents and source code
▪ Choosing test conditions
▪ Designing and execution
▪ Checking results
▪ Evaluate exit criteria
▪ Reporting on the test process and system under test
▪ Closure activities after the test phase has completed

17
What is Testing?(2/3) : Test Objectives
• Testing can have the following objectives:
• Finding defects
✓Eg. Developer testing, component, integration and system testing

• Gaining confidence about the level of quality

✓Eg. Acceptance testing

• Providing information for decision-making

✓Eg. Assess quality with no intention of fixing defects
✓Eg. Information on risk of releasing for decision making

• Preventing defects
✓Eg. early testing by reviewing requirements

18
What is Testing?(3/3) : Debugging and Testing are different
• Dynamic testing where the software is running shows failures (an anomaly or
unexpected event) caused by defects (flaws or faults)

• Debugging is a development activity that finds, analyses and removes the cause of the
failure.

Tip: Be sure of terminology used by checking

the ISTQB glossary at the back of your notes.

Defect = Flaw = Bug

Failure = Deviation = Anomaly = Incident

19
 Topic 1.3

SEVEN TESTING PRINCIPLES

20
Seven Testing Principles(1/4) : ISTQB Testing
Principles

The syllabus tells us…

“A number of testing principles have been suggested over the past 40 years
and offer general guidelines common for all testing.”

21
Seven Testing Principles(2/4)

1 – Testing shows a presence of defects

• Testing shows that defects are present
• But cannot prove that there are no defects

2 – Exhaustive testing is impossible

• Can’t test all combinations of inputs and preconditions
• Instead do risk analysis and prioritize to focus testing efforts

3 – Early Testing
• Start testing early to find defects as early as possible
• Focus on test objectives

22
Seven Testing Principles(3/4)

4 – Defect Clustering
• A small number of modules usually contain most of the
defects
• Testing effort should be focused proportionally to the defect
density

5 – Pesticide Paradox
• If the same tests are repeated over and over, eventually the
same set of tests will no longer find any new defects
• Test cases need to be regularly reviewed, revised and
updated – consider data, order of execution, etc to exercise
different paths

23
Seven Testing Principles(4/4)

6 – Testing is context dependent

• Not all testing has the same thoroughness
• We test differently in different contexts
• Eg. Safety critical vs. informational website

7 – Absence-of-errors fallacy
• Finding and fixing defects doesn’t help if the system is
unusable or does not meet users’ needs and expectations
• Eg. If the requirement is wrong to begin with

24
Topic 1.4
Fundamental Test Process

25
Fundamental Test Process(1/6) : 5 STEPS

Monitoring and Control activities happen throughout

3. 4. Evaluate
5. Test
1. Planning 2. Analysis Implementa exit criteria
Closure
and Control and Design tion and and
Activities
Execution reporting

26
Fundamental Test Process(2/6) : Step 1

• Planning
• Define objectives of testing
Planning and
• Specify test activities in order to meet the objectives and Control
mission

• Control
• Is the ongoing activity of comparing actual progress with plan
• Report the status, including deviations from plan
• Take action necessary to meet objectives
• You can’t control testing without monitoring
• Planning takes into account feedback from monitoring and control

27
Fundamental Test Process(3/6) : Step 2

• The general testing objectives are transformed

into tangible test conditions and test cases
Analysis and
Design
• Review the test basis (such as requirements, architecture,
design and interface specifications)
• Evaluate testability
• Identify and prioritise Test conditions
• Design high level test cases and prioritise
• Identify test data
• Design test environment and required infrastructure and tools
• Create bi-directional traceability between test basis and test cases

28
Fundamental Test Process(4/6) : Step 3
• Test procedures and scripts are created by specifying
the order of test cases and any other information
required to run the test Implementa
• Finalise tests cases including data tion and
Execution
• Develop test procedures
• Create test data (optionally create test harness or automated scripts)
• Create test suite from test procedures for efficient testing
• Verify test environment has been set up correctly
• Verify and update traceability
• Execute test procedures
• Log outcomes and compare actual with expected results
• Report discrepancies as incidents and analyse to establish if likely cause is defect in
code, test data, test document or mistake
• Repeat test activities to confirm a fix (confirmation) or regression testing

29
 Fundamental Test Process(5/6) : Step 4

• Assess test activity against defined objectives Evaluate exit

criteria and
Reporting
• Check test logs against exit criteria specified in
test planning
• Assess if more tests are needed or if the exit criteria
should be changed
• Write a test summary report for stakeholders

30
 Step 5 of Fundamental Test Process

• Collect data from completed test activities and consolidate

Test Closure
experience, test ware, facts and numbers.

• Check which planned deliverables have been delivered

• Close incident reports or raise change records for any that remain open
• Document acceptance of the system
• Finalise and archive test ware, test environment and infrastructure for later re-use
• Hand over test ware to maintenance team
• Analyse lessons learnt to determine changes needed for future releases and projects
• Use information gathered to improve test maturity

31
 Topic 1.5

THE PSYCHOLOGY OF TESTING

32
The psychology of testing (1/4) :
Should developers test their own code?

YES!

33
The psychology of testing (2/4) : The testing
mindset
• The mindset used to create something is different to the one used to review.
With the right mindset developers are able to test their own code, but
independence brings additional benefits

• People and projects are driven by objectives

– therefore it is important to clearly state
the objectives of testing

• Identifying failures during testing may be

perceived as criticism, as a result testing is
often seen as a destructive activity

34
 The psychology of testing (3/4): Communication

• Errors, defects or failures need to be communicated in a constructive way to avoid bad

feelings between testers, analysts and developers

• Testers need good interpersonal skills

to communicate factual information

• To improve communication:
• Collaborate rather than have battles
(common goal of better quality systems)
• Communicate in a neutral, fact-focused way without criticising
• Try to understand how the other person feels
• Confirm that the other person has understood

35
 The psychology of testing (4/4) : Independence

• Independence makes the tester more effective at finding defects and failures
• However – it does not replace familiarity and developers can efficiently find many defects in their
own code

• Levels of Independence (from low to high)

• Tests designed by person that wrote software
• Tests designed by another person (from the dev team)
• Tests designed by someone from another group ( e.g.. An independent test team) or test
specialists (eg. Usability or performance)
• Tests designed by someone from a different organization or company (i.e.. Outsourcing or
certification by an external body)

36
 TOPIC 1.6

CODE OF ETHICS

37
 Code of Ethics(1/4) : Why do we need a Code of
Ethics?

• Involvement in software testing enables testers to learn confidential and privileged

information

• ISTQB recognises the ACM and IEEE code of ethics for engineers and states
the following code of ethics:

38
Code of Ethics(2/4) : ISTQB Code of Ethics

39
Code of Ethics(3/4) : ISTQB Code of Ethics

• Test managers and leaders shall subscribe to and

5. MANAGEMENT promote an ethical approach

• Advance the integrity and reputation of the

6. PROFESSION profession consistent with public interest

• Be fair to and supportive of their colleagues and

7. COLLEAGUES promote co-operation with the public interest

• Participate in lifelong learning regarding the practice

8. SELF of their profession and promote an ethical approach

40
End of Module 1

Questions?

41
End of Module Learning Check - 1

To avoid or reduce risk of loss of money, time, reputation, injury or death

To find defects, gain confidence , to provide information

Failure is an anomaly, unexpected event. Defect is a fault in code or doc

Mistakes caused by time pressures, project constraints and complexity

Test early, Testing shows a presence of defects,

Exhaustive testing is impossible, Defect cluster,
Pesticide Paradox, Absence-of-errors fallacy,
Testing is context dependent

42
End of Module Learning Check - 2
6. What is the fundamental test process?
Planning and Control, Analysis and Design, Implementation and Execution, Evaluate Exit Criteria and Reporting
Test Closure

7. What activities are in Test Closure?

Check deliverables have been delivered, close incident reports,
raise change requests, document acceptance, finalise and archive
testware, hand over to maintenance, lessons learned, improve test maturity
8. Which step of the Fundamental Test Process does “identifying test data” fall in to?
Analysis and Design

9. What is the code of ethics for testers?

Public, Client and Employer, Self, Product, Management, Profession
Colleagues, Judgement

43
ISQTB Sample Exam Practice Question 1

Which one of the following describes best the difference between testing and debugging?
A. Testing shows failures that are caused by defects.
Debugging finds, analyzes, and removes the causes of failures in the software.
B. Testing pinpoints the defects. Debugging analyzes the faults and proposes preventing
activities.
C. Testing removes faults. Debugging identifies the causes of failures.
D. Dynamic testing prevents causes of failures. Debugging removes the failures.

44
ISQTB Sample Exam Practice Question 2
Below you find a list of descriptions of problems that can be observed during testing or
operation. Which is most likely a failure?

A. The product crashed when the user selected an option in a dialog box.
B. One source code file included in the build was the wrong version
C. The computation algorithm used the wrong input variables.
D. The developer misinterpreted the computational requirement for that algorithm.

45
Reference
1. ISTQB Certified Tester Foundation Level Syllabus,
Version 2010, pp10-19
2. http://gizmodo.com/5467388/software-bug-causes-toyota-rec
all-of-almost-half-a-million-new-hybrid-cars
3. www.istqb.org
4. http://www.istqb.org/display/ISTQB/Downloads?atl_token=9v
oKHV6hij
5. www.anztb.org
6. All images without reference are provided by Microsoft
7. ISTQB Practice exam questions
-LO-1.1.5-Q1-K2
-LO-1.2.3_Q1_K2

46
Software Systems(1/4)

Software is an integral part of life

▪ Business applications (eg. banking, factory machines)

▪ Consumer products (eg. cars, washing machines)

Software is everywhere!
What bugs
Example where software didn’t work correctly… have you
found?
In 2010 the Toyota Prius was dogged by software
bugs that caused uneven braking in the car’s antilock
brake system (ABS). Toyota had to recall nearly half a
million of these hybrid cars.

47
 Software Systems(2/4)
What are some of the consequences of faulty software?

Loss of Injury or Loss of

Loss of Money Loss of Time
Reputation Life

Example :
Example : Example :
Brand was Example:
A company A defect
damaged by
gets sued caused a Malfunction
ongoing
because an delay in a call of switching
performance
advertised center, so in a railway
business issues of a
that not as line caused
listing didn’t major airline,
many calls trains to
display so customers
could be collide
correctly went
answered
elsewhere

48