Software Testing

ISTQB / ISEB Foundation Exam Practice

Fundamentals of Testing

1. Fundamentals 2. Testing in SDLC 3. Static Testing

4. Test 5. Test
6. Tools
Techniques Management

Chapter 1
 CONTENT

•What is testing?

•Why testing is necessary

•Testing principles

•Fundamental test process

•Psychology of testing

•Code of Ethics
 What is Testing?: Background

• Most people have had an experience with software that did not
work as expected
• Software that does not work correctly can lead to many
problems, including:
o loss of money, time, or business reputation
o injury or death (can you think of an example?)
 What is Testing?: Cost of Software Faults

•Huge sums
o Ariane 5 ($7billion)
The Explosion of the Ariane 5 (umn.edu)
o Mariner space probe to Venus ($250m)
Mariner 1 destroyed due to code error, July 22, 1962 – EDN
o American Airlines ($50m)
•Very little or nothing at all
o minor inconvenience
o no visible or physical detrimental impact
•Software is not “linear”:
o small input may have very large effect
 What is Testing?: Safety-critical systems

•Software faults can cause death or injury

o radiation treatment kills patients (Therac-25)
o train driver killed
o aircraft crashes (Airbus & Korean Airlines)
o bank system overdraft letters cause suicide
Debt lad’s suicide note …on letter from bank – The Sun
 What is Testing?

•No generally accepted set of testing definitions used world-wide

•New testing standard BS 7925-1
o Glossary of testing terms (emphasis on component testing)
o most recent
o developed by a working party of the BCS SIGIST
o adopted by the ISEB / ISTQB
Working Draft of BS 7925-1 (testingstandards.co.uk)
 What is Testing?

The process consisting of all lifecycle activities, both

static and dynamic, concerned with planning,
preparation and evaluation of a component or system
and related work products to determine that they
satisfy specified requirements, to demonstrate that
they are fit for purpose and to detect defects.
Source: ISTBQ glossary
• Software testing is a way to:
o assess the quality of the software
o reduce the risk of software failure in operation
 Question

Which of the following is a main goal of software

testing?
a. Assess the quality of the software
b. Increase the quality of the software
 Question

If you find a defect while you are testing the software

early in the lifecycle, what will be impacted by this
action?
a. Risk of finding this defect in operation will increase
b. Risk of finding this defect in operation will not be
impacted
c. Risk of finding this defect in operation will be reduced
 Question

What is the main role of the tester in software projects?

a. resolve defects
b. develop applications
c. find defects
 Question

Software testing is a way to …

a. Increase the quality of the software
b. Reduce the risk of software failure in operation
 What is Testing?: Misperceptions

• Software testing ≠ Test execution

o Software testing is a process which includes many different
activities
o Execution is only one of these activities
 What is Testing?: Misperceptions

Static
Testing
Software
Testing

Dynamic
Testing
 What is Testing?: Misperceptions

Validation

Software
Testing

Verification
 What is Testing?: Misperceptions

VERIFICATION VALIDATION
•2 sleeves? •Does it fit?
•Is it size L? •Will my crush like it?
•Is it blue? •Can I afford it?
•Are any button •Does it feel comfortable to
missing? wear?
•Does the colour match my
eyes?
 Question

Software testing is not the same as test execution, because

software testing is a process and test execution is just one step in
this process. The test process consists of 7 steps, do you
remember the order of test execution in them?
a. 4
b. 5
c. 6
d. 7
 Question

If you get a code from the developer and your task is to test
whether the developer added proper commenting to his code or
not, which type of testing is this?
a. Dynamic Testing
b. Static Testing
 Question

Building the right product and building the product right, which
one of them is validation and which is verification?
a. Building the right product is validation and building the
product right is verification.
b. Building the right product is verification and building the
product right is validation
 Question

If a developer runs his code and finds a defect in it, this is

called............
a. static testing
b. dynamic testing
c. system testing
 What is Testing?: Objectives of Testing

Work Product Requirement Building

Evaluation Fulfilment Confidence

Providing
Preventing Finding
Information to
Defects Defects
Stakeholders

Compliance Objectives
Reducing Risks
with Law may vary
 Question

Which of the following can be considered as one main objective

of software testing?
A. Market our product to potential customers
B. Give the client good knowledge about the status of the
project
C. Evaluate other team members and make a decision about
their eligibility to get a bonus
 Question

If the tester reviewed the requirements and found a

contradiction between two requirements, which objective of
testing can be obtained using this activity?
A. Building confidence
B. Compliance with laws
C. Preventing defects
 Question

Component (unit) testing is a test level that focuses on individual

hardware or software components, and it always happens early
in the software lifecycle.
Depending on this definition, what testing objective can be
obtained using component testing?
A. Reduce risk
B. Give information to stakeholders
C. Compliance with laws
 Question

Which of the following is not an objective of software testing?

A. requirements fulfilment
B. building confidence in components
C. Preventing defects
D. reducing project duration
 Question

When test cases are designed early in the lifecycle, verifying the
test basis via the test design, which common test objective is
being achieved?
A. Gaining confidence
B. Finding defects
C. Preventing defects
D. Providing information for decision making
 Question

If you are making sure that what you have built is the same as
what the client wants, which test objective is mostly met by this
activity?
A. reducing risks
B. finding defects
C. requirements fulfilment
 What is Testing?: Testing & Debugging
The process of
The activity to
finding, analysing
ensure that the
& removing the
fix does resolve
causes of failures
the failure
in software

Confirmation
Testing Debugging
Testing
Tester’s job Dev’s job Tester’s job

In Agile development and in some other lifecycles, testers may be

involved in debugging and component testing.
 Question

Which of the following is a correct definition to debugging?

a. Testing/checking whether the software performs correctly
b. Checking that no unintended consequence have occurred as
a result of a fix
c. Identifying the cause of a defect, repairing the code &
checking if the fix is correct
d. Checking that previously reported defect has been corrected
 Question

In which lifecycle may testers be involved in debugging and

component testing?
a. Waterfall Model
b. Agile Development
c. V-Model
 Question

Which of the following is an example of debugging?

a. A tester finds a defect & reports it
b. A tester retests a fix from the developer & finds a regression
c. A developer finds & fixes a defect
d. A developer performs unit testing
 Question

Which of the following statements BEST describes the difference

between testing & debugging?
a. Testing pinpoints the defects. Debugging analyses the faults
& proposes prevention activities.
b. Dynamic testing shows failures caused by defects. Debugging
finds, analyses, and removes the causes of failures in the
software.
c. Testing removes faults. Debugging identifies the causes of
failures.
d. Dynamic testing prevents causes of failures. Debugging
removes the failures.
 CONTENT

•What is testing?

•Why testing is necessary

•Testing principles

•Fundamental test process

•Psychology of testing

•Code of Ethics
 Why is Testing Necessary?

• Rigorous testing reduces the risk of failures occurring during

operation.
• When defects are fixed, quality increases.
• Testing verifies that a system is correctly built & validates that it
will meet user’s and stakeholders’ needs.
• Software testing may also be required to meet contractual or
legal requirements or industry-specific standards
 Testing’s Contributions to Success

• Having testers involved in requirements reviews or user story

refinement could detect defects in these work products.

•Identifying & removing defects at this stage

reduces the risks of the wrong software
(incorrect or untestable) being developed.
 Testing’s Contributions to Success

• Having testers work closely with system designers while the

system is being designed can increase each party’s understanding
of the design and how to test it.

• Better understanding at this stage can

reduce the risk of fundamental design
defects & enable tests to be identified at an
early stage.
 Testing’s Contributions to Success

• Having testers work closely with developers while the code is

under development can increase each party’s understanding of
the code and how to test it.

• This increased understanding can reduce

the risk of defects within the code and the
tests.
 Testing’s Contributions to Success

• Having testers verify and validate the software prior to release

can detect failures that might otherwise have been missed, and
support the process of removing the defects that caused the
failures (i.e., debugging).

• This increases the likelihood that the

software meets stakeholder needs &
satisfies requirements.
 Quality Assurance & Testing

•Quality management refers to all activities that direct and control

an organization with regard to quality in all aspects.
o Quality affects not only software development but also HR
procedures, delivery processes & so on.

•Quality assurance, part of quality management, is typically

focused on adherence to proper processes.
o Proper processes → Work products higher quality

• Quality control is concerned with the quality of the products

rather than processes.
o Testing is a quality control activity rather than a quality assurance
activity.
 Errors - Defects - Failures

•Error (mistake): a human action that produces an incorrect

result
•Defect (fault/bug): a manifestation of an error in software
o if executed, a fault may cause a failure
•Failure: an event in which a component or system does not
perform a required function within specified limits
o found defect

Failure is an event; defect is a state of

the software, caused by an error.
 Errors - Defects - Failures

A person makes
an error ...

… that creates a
defect in the
software ...

… that can cause

a failure
in operation
 Errors - Defects - Failures

• Common thought: failures = result of "bug in the code"

• 20% of defects in requirements, 25% in design
Errors - Defects - Failures
 Errors - Defects - Failures

Failure

Error Defect

No Failure
 Why do errors happen?

•Time pressure
• Human fallibility
• Lack of experience
• Miscommunication
• Complexity of work products
• System interactions
• New technologies
• Environmental conditions
 What do software faults cost?

Figure 1.2 Multiplicative increases in cost

Cost to Repair

16X

8X
4X
1X
2X

Requirement Design Code/Unit Independent After Release

Test Test
 So why is testing necessary?

• because software is likely to have faults

• to learn about the reliability of the software
• to fill the time between delivery of the software and the release
date
• to prove that the software has no faults
• because testing is included in the project plan
• because failures can be very expensive
• to avoid being sued by customers
• to stay in business
 Defects – Root Causes – Effects

• Root cause: a source of a defect such that if it is removed, the

occurrence of the defect type is decreased or removed.

•Root cause analysis can lead to

process improvements that prevent
a significant number of future
defects from being introduced.
 Defects – Root Causes - Effects

For example, suppose incorrect interest payments, due to a single

line of incorrect code, result in customer complaints
The defective code was written for a user story which was
ambiguous, due to the product owner’s misunderstanding of how
to calculate interest.

• Failure: incorrect calculations for customers

• Defect: the wrong calculation in the code
• Root cause: the product owner’s lack of
knowledge on interest calculation
• Effect: customer complaints
 Question

Which one of the statements below describes a failure discovered

during testing or in production?
A. The product crashed when the user selected an option in a
dialog box
B. The wrong version of one source code file was included in the
build
C. The computation algorithm used the wrong input variables
D. The developer misinterpreted the requirement for the
algorithm
 Question

From your comprehension of Root cause analysis, choose the

correct answer:
A. Root cause analysis can be applied in software environment
only
B. Root causes of defects are the earliest actions that contributed
to creating the defect but it will destroy the process
C. Root cause analysis can be applied in all life cycle steps and can
prevent a significant number of future defects from being
introduced
 Question

Which of the following is a correct statement?

A. A developer makes an error which results in a failure that
may be seen as a fault when the software is executed
B. A developer has a failure which results in a defect that may
be seen as a mistake during dynamic testing
C. A developer makes a mistake which causes a defect that may
be seen as a failure during dynamic testing
D. A developer makes a mistake which causes a bug that may
be seen as a defect when the software is executed
 Question

Which of the following statements are TRUE?

1 – Software testing may be required to meet legal or contractual requirements
2 – Software testing is mainly needed to improve the quality of the developer’s
work
3 – Rigorous testing & fixing of defects found can help reduce the risk of
problems occurring in an operational environment
4 – Rigorous testing is sometimes used to prove that all failures have been
found
A. 2 & 3 are true, 1 & 4 are false
B. 1 & 4 are true, 2 & 3 are false
C. 1 & 3 are true, 2 & 4 are false
D. 3 & 4 are true, 1 & 2 are false
 CONTENT

•What is testing?

•Why testing is necessary

•Testing principles

•Fundamental test process

•Psychology of testing

•Code of Ethics
 Seven Testing Principles

1. Testing shows the presence of defects

• Testing can show that defects are present but cannot prove
that there are no defects.

• Testing reduces the probability of undiscovered defects

remaining in the software but, even if no defects are found, it
is not a proof of correctness.
 Seven Testing Principles

2. Exhaustive testing is impossible

• Testing everything (all combinations of inputs and
preconditions) is not feasible except for trivial cases.
 Why not just "test everything"?

Avr. 4 menus
3 options / menu

20 screens Average: 10 fields / screen

2 types input / field
(date as Jan 3 or 3/1)
(number as integer or decimal)
Around 100 possible values

Total for 'exhaustive' testing:

20 × 4 × 3 × 10 × 2 × 100 = 480,000 tests
If 1 second per test, 8000 mins, 133 hrs, 17.7 days
(not counting finger trouble, faults or retest)
 Exhaustive testing?

•What is exhaustive testing?

o when all the testers are exhausted
o when all the planned tests have been executed
o exercising all combinations of inputs and preconditions

•How much time will exhaustive testing take?

o infinite time
o not much time
o impractical amount of time
 How much testing is enough?

• It's never enough

• When you have done what you planned
• When your customer/user is happy
• When you have proved that the system works correctly
• When you are confident that the system works correctly
• It depends on the risks for your system
 How much testing?

It depends on RISK
• Risk of missing important faults
• Risk of incurring failure costs
• Risk of releasing untested or under-tested software
• Risk of losing credibility and market share
• Risk of missing a market window
• Risk of over-testing, ineffective testing
 So little time, so much to test ..

Test time will always be limited

• Use RISK to determine:

o what to test first

}
o what to test most i.e. where to
o how thoroughly to test each item place emphasis
o what not to test (this time)

• Use RISK to
o allocate the time available for testing by prioritising testing ...
 Most important principle

Prioritise tests so that,

whenever you stop testing,
you have done the best
testing in the time available.
 Other factors that influence testing

•Contractual requirements
•Legal requirements
•Industry-specific requirements
o e.g. pharmaceutical industry (FDA), compiler standard tests, safety-
critical or safety-related such as railroad switching, air traffic control

It is difficult to determine how

much testing is enough, but it is
not impossible.
 Seven Testing Principles

3. Early testing
• Testing activities (both static & dynamic) should start as early
as possible in the software/system development life cycle and
should be focused on defined objectives.
• Early testing is sometimes referred to as "shift left". Testing
early in the SDLC helps reduce or eliminate costly changes.
 Seven Testing Principles

4. Defect clustering
• A small number of modules contain most of the defects
discovered during pre-release testing, or they are responsible
for most of operational failures.
• Predicted defect clusters, and the actual observed defect
clusters in test or operation, are an important input into a risk
analysis used to focus the test effort.
 Seven Testing Principles

5. Pesticide paradox
• If the same tests are repeated over and over again,
eventually these tests no longer find any new defects.
• To detect new defects, existing tests & test data are changed,
and new tests need to be written.
 Seven Testing Principles

6. Testing is context dependent

• Testing is done differently in different dependent contexts.
E.g., safety-critical software is tested differently from an e-
commerce site.
 Seven Testing Principles

7. Absence-of-errors fallacy
• Finding and fixing defects does not help if fallacy the system
built is unusable and does not fulfill the users' needs and
expectations.
 Question

Which of the following statements CORRECTLY describes one of

the seven key principles of software testing?
a. By using automated testing it is possible to test everything
b. With sufficient effort and tool support, exhaustive testing is
feasible for all software
c. It is normally impossible to test all input/output combinations
for a software system
d. The purpose of testing is to prove the absence of defects
 Question

Why is it important to avoid the pesticide paradox?

a. Dynamic testing is less reliable in finding bugs
b. Pesticides mixed with static testing can allow bugs to escape
detection
c. Tests should not be context dependent
d. Running the same tests over & over will reduce the chance of
finding new defects
 Question

Which of the following is a true statement about exhaustive

testing?
a. It is a form of stress testing
b. It is not feasible except in the case of trivial software
c. It is commonly done with test automation
d. It is normally the responsibility of the developer during unit
testing
 Question

A test team consistently finds between 90% and 95% of the defect present
in the the system under test. While the test manager understands that
this is a good defect detection percentage for her test team and industry,
senior management and executes remain disappointed in the test group,
saying that the test team misses too many bugs. Given that the users are
generally happy with the system and that the failures which have occurred
have generally been low impact, which of the following testing principles
is most likely to help the test manager explain to these managers and
executives why some defects are likely to be missed?
a. Pesticide paradox
b. Defect clustering
c. Exhaustive testing is impossible
d. Absence of error fallacy
 Question

A programmer is working on code which is very complex. Which of

the following is a general testing principle that may affect his
work?
a. Pesticide paradox
b. Defect clustering
c. Absence of error fallacy
d. Exhaustive testing is impossible
 CONTENT

•Why testing is necessary

•What is testing

•Testing principles

•Test process

•Psychology of testing

•Code of Ethics
 Test Process

• There is no 'one size fits all' test process

• But testing needs to include common set of activities without
which testing will be less likely to achieve its established
objectives
 Test Process in Context

• Test basis is the body of knowledge used as the basis for test
analysis and design.
o it is whatever the tests are being derived from (user requirement,
user story, design, or code)

• It is useful if the test basis has measurable coverage criteria

defined.

•Coverage: the degree to which specified coverage items have

been determined to have been exercised by a test suite,
expressed as a percentage.
 Test Process in Context

•For example, for a mobile application, the test basis may include
a list of requirements and a list of supported mobile devices.
o Each requirement is an element of the test basis. Each supported
device is also an element of the test basis.

•The coverage criteria may require at least one test case for each
element of the test basis.
•Once executed, the results of these tests tell stakeholders
whether specified requirements are fulfilled and whether failures
were observed on supported devices.
 Test Process Activities

Test Test Test

Test
Plannin Test Test
Implem Test
Compl
g
Planning Analysis entation
Implementation etion
Completion

Test
Test Test Text
Monitoring
Monitoring Design Execution
&& Control
Control
 Test Process Activities

• Although these activities appear logically sequential, they may

overlap or take place concurrently or iteratively.
• Each group of activities consist of many individual tasks; these
will vary for different projects or releases.

Test Test Test

Test
Plannin Test Test
Implem Test
Compl
g
Planning Analysis entation
Implementation etion
Completion

Test
Test Test Text
Monitoring
Monitoring Design Execution
&& Control
Control
 Step 1. Test Planning

• Test planning involves defining objectives of testing & the

approaches for meeting those objectives within project
constraints and contexts.
•This includes deciding on suitable test techniques to use, what
tasks need to be done, formulating a test schedule, etc.
 Step 2. Test Monitoring and Control

•Test monitoring. On-going comparison of actual progress against

the test plan using any test monitoring metrics defined in the test
plan
•Test control. Taking actions necessary to meet the objectives of
the test plan
•Supported by exit criteria or DoD (Definition of Done)
•Test progress against the plan is communicated to stakeholders
in test progress reports
 Step 3. Test Analysis

•Test condition. An aspect of the test basis that is relevant in

order to achieve specific test objectives.
• Test analysis. The activity that identifies test conditions by
analysing the test basis (i.e., reqs. specs., design, code, risk
analysis report).
•Test analysis answers the question – "What to test?"
•Capturing bi-directional traceability
•Test conditions can be used as objectives in Test Charters
 Step 4. Test Design

•Answer the question "How to Test"

•Design and prioritize test cases
•Identify test data
•Design test environment
 A good test case

• Effective Finds faults

• Exemplary
Represents others

• Evolvable
Easy to maintain
• Economic

Cheap to use
Step 4. Test Design (cont.)
 Step 5. Test Implementation

•Answer the question "Do we now have everything in place to run

the tests?"
•Develop and prioritize test procedures
•Create test suites, arrange them in test execution schedule
•Build test environment
 Step 6. Test Execution

Test suites are run according to the test execution schedule

•Compare actual result with expected result
o Differences are referred as anomalies
o Analyse anomalies to identify their causes (defects in code, false-
positives, or test defects)
•Report defects based on failures observed
•Confirmation and/or Regression Testing
Step 6. Test Execution (cont.)
 Step 7. Test Completion

•Collect data from completed test activities

•Occurs at project milestones
•Check Defect Reports
•Create Test Summary Report
•Hand over the testware (Why?)
 Test Work Products

Activity Work Products

Test Planning Test Plans
Test Monitoring & Test Progress/Summary Reports
Control
Test Analysis Test Conditions – Test Charters
Test Design Test Cases – Test Data
Test Implementation Test Procedures – Test Suites – Test Execution
Schedule
Test Execution Status of Test Cases – Defect Reports
Test Completion Test Summary Reports – Change Requests
 Comparison of tasks
Governs the
quality of tests

Planning Intellectual

one-off
Specification activity
activity Good to
Execute repeated automate
many times

Recording Clerical
 Question

When following the fundamental test process, when should the

test control activity take place?

A. During the planning activities

B. During the implementation and execution activities
C. During the monitoring activities
D. During all the activities
 Question

Which of the following is the activity that compares the planned

test progress to the actual test progress?

A. Test monitoring
B. Test planning
C. Test closure
D. Test control
 Question

Designing and prioritizing test cases occurs during which activity

in the fundamental test process?
A. Test Planning
B. Test Analysis
C. Test Design
D. Test Completion
 Question

Designing and prioritizing test conditions based on analysis of the

test basis occurs during which activity in the fundamental test
process?
A. Test Planning
B. Test Analysis
C. Test Design
D. Test Completion
 Question

Checking whether all defect reports are closed occurs during

which activity in the fundamental process?
A. Test Planning
B. Test Analysis
C. Test Design
D. Test Completion
 Question

Comparing actual results with expected results occurs during

which activity in the fundamental process?
A. Test Monitoring & Control
B. Test Analysis
C. Test Implementation
D. Test Execution
 Question

Developing and prioritizing test procedures occurs during which

activity in the fundamental process?
A. Test Monitoring & Control
B. Test Analysis
C. Test Implementation
D. Test Execution
 Question

Checking test results and test logs against specified coverage

criteria occurs during which activity in the fundamental process?
A. Test Monitoring & Control
B. Test Analysis
C. Test Implementation
D. Test Execution
 CONTENT

•Why testing is necessary

•What is testing

•Testing principles

•Fundamental test process

•Psychology of testing

•Code of Ethics
 Why test?

•build confidence

•prove that the software is correct

•demonstrate conformance to requirements

•find faults

•reduce costs

•show system meets user needs

•assess the software quality

 Assessing software qualityyou
You think
are here

Many High Few

Few
Faults Faults
Faults

Low High
Software Quality

Few Test Few

Faults Quality Faults

You may
be here

Low
 Independence

Test one’s own work?

• Find 30% - 50% of your own faults
• Same assumptions and thought processes
• See what one meant or wants to see, not what is there
• Emotional attachment
o Don’t want to find faults
o Actively want NOT to find faults
 Levels of independence

1. None: tests designed by the person who wrote the software

2. Tests designed by a different person w/I the dev team
3. Tests designed by someone from a different department or
team (e.g. test team)
4. Tests designed by someone from a different organisation (e.g.
agency)
5. Tests generated by a tool (low quality tests?)
 Human Psychology & Testing

•Identifying defects may be perceived as criticism of the product

and of its author.
•Confirmation bias can make it difficult to accept information that
disagree with currently held beliefs,
•Cognitive biases may make it difficult for people to understand or
accept information produced by testing.
•It is a common human trait to blame the bearer of bad news.

•Some people may perceive testing as a destructive activity

•Try to reduce these perceptions by having the right attitudes,
and communicating in a constructive way.
 Attitudes & Communications

•Start with collaboration rather than battles. Remind everyone of the

common goal of better quality systems.
•Emphasize the benefits of testing.
o for the authors, defect information can help them improve their work
products and their skills.
o for the organization, defects found and fixed during testing will save time
and money and reduce overall risk to product quality
•Communicate test results and other findings in a neutral, fact-focused
way without criticizing the person who created the defective item.
•Write objective and factual defect reports and review findings
•Try to understand how the other person feels and the reasons they
may react negatively to the information.
•Confirm that the other person has understood what has been said and
vice versa.
 A traditional testing approach

• Show that the system:

o does what it should
o doesn't do what it shouldn't

Goal: show working

Success: system works

Fastest achievement: easy test cases

Result: faults left in

 A better testing approach

•Show that the system:

o does what it shouldn't
o doesn't do what it should

Goal: find faults

Success: system fails

Fastest achievement: difficult test cases

Result: fewer faults left in

 The testing paradox

Purpose of testing: to find faults

Finding faults destroys confidence
Purpose of testing: destroy confidence

Purpose of testing: build confidence

The best way to build confidence

is to try to destroy it
 Who wants to be a tester?

• A destructive process
• Bring bad news (“your baby is ugly”)
• Under worst time pressure (at the end)
• Need to take a different view, a different mindset (“What if it
isn’t?”, “What could go wrong?”)
• How should fault information be communicated (to authors and
managers?)
 Testers have the right to:

o Accurate information about progress and changes

o Insight from developers about areas of the software
o Delivered code tested to an agreed standard
o Be regarded as a professional (no abuse!)
o Find faults!
o Challenge specifications and test plans
o Have reported faults taken seriously (non-reproducible)
o Take predictions about future fault levels
o Improve your own testing process
 Testers have responsibility to:

o Follow the test plans, scripts etc. as documented

o Report faults objectively and factually (no abuse!)
o Check tests are correct before reporting s/w faults
o Remember it is the software, not the programmer, that is being
tested
o Assess risk objectively
o Prioritise what are reported
o Communicate the truth
 CONTENT

•Why testing is necessary

•What is testing

•Testing principles

•Fundamental test process

•Psychology of testing

•Code of Ethics
 Code of Ethics

ISTQB Code of Ethics:

• Public – Certified software testers shall act consistently with the
public interest.
• Client & Employer – Certified software testers shall act in a
manner that is in the best interests of their client and employer,
consistent with the public interest.
• Product – Certified software testers shall ensure that the
deliverables they provide (on the products and systems they test)
meet the highest professional standards possible.
• Judgment – Certified software testers shall maintain integrity
and independence in their professional judgment.
 Code of Ethics

•Management – Certified software test managers and leaders

shall subscribe to and promote an ethical approach to the
management of software testing.
•Profession – Certified software testers shall advance the integrity
and reputation of the profession consistent with the public
interest.
•Colleagues – Certified software testers shall be fair to and
supportive of their colleagues; and promote cooperation with
software developers.
•Self – Certified software testers shall participate in lifelong
learning regarding the practice of their profession and shall
promote an ethical approach to the practice of the profession.