Chapter 1 - Fundamentals of Testing V4.0

FIRST ON INTERNET WITH NEW SYLLABUS
ISTQB Foundation 4.0
SUMMARY & EXAM Structure
#Tutorial 60 – Closing Notes

ISTQB
Foundation
New Syllabus
4.0

Neeraj Kumar Singh
Global Testing Consultant
ISTQB Certified instructor with 16+ years of experience in Training and
delivery. Also a certified Global testing Consultant for Test Process and Tools
implementation. Have delivered 700+ training for 15000+ participants in
120+ corporate Organisation across 28 Countries.
Instructor | Consultant | Author
World’s best instructor on ISTQB Certification - Google

TM
© 2023. All Rights Reserved
INTRODUCTION TO ISTQB
➢ International Software Testing Qualification Board
➢ About ISTQB
➢ Certifications
➢ Local body conducting exam
➢ What’s the cost?
➢ Validity

TM
CERTIFICATIONS

TM
INTRODUCTION TO ISTQB
➢ Prerequisite
➢ Exam type – Objective
➢ Number of Questions – 40
➢ Duration – 60 Min
➢ Schedule
➢ Location/Venue
➢ Passing score – 26 or More
➢ Additional info – New Revision 4.0
About Examination

TM
ISTQB Foundation Exam
➢ Chapter 1 – Fundamentals of Testing
➢ Chapter 2 – Testing Throughout the Software Development Life Cycle
➢ Chapter 3 – Static Testing
➢ Chapter 4 – Test Analysis & Design
➢ Chapter 5 – Managing The Test Activities
➢ Chapter 6 – Test Tool
The Syllabus

TM
ISTQB Foundation Exam
➢ K1 – Remember
➢ K2 – Understand
➢ K3 – Apply
➢ K4 - Analyze
K Levels

Fundamentals of Testing
1 Fundamentals
2 Testing
in Lifecycle
4 Analysis
& Design
3 Static testing
5 Test
Management
6 Test Tools
ISTQB Foundation
Chapter -1

TM
Content
1.1 What is Testing?
1.2 Why is Testing Necessary?
1.3 Testing Principles
1.4 Test Activities, Testware & Test Roles
1.5 Essential Skills and Good Practices in Testing

TM
 Software testing is a set of activities to discover defects and evaluate the quality of software artifacts.
These artifacts, when being tested, are known as test objects.
 A common misconception about testing is that it only consists of executing tests (i.e., running the software
and checking the test results).
 Another common misconception about testing is that testing focuses entirely on verifying the test object.
 Testing may be dynamic or static.
 Testing is not only a technical activity. It also needs to be properly planned, managed, estimated,
monitored and controlled
What is Testing?

TM
The typical test objectives are:
 Evaluating work products such as requirements, user stories, designs, and code
 Triggering failures and finding defects
 Ensuring required coverage of a test object
 Reducing the level of risk of inadequate software quality
 Verifying whether specified requirements have been fulfilled
 Verifying that a test object complies with contractual, legal, and regulatory requirements
 Providing information to stakeholders to allow them to make informed decisions
 Building confidence in the quality of the test object
 Validating whether the test object is complete and works as expected by the stakeholders
Test Objectives

TM
 Testing and debugging are separate activities.
 Testing can trigger failures that are caused by defects in the software (dynamic testing) or can directly
find defects in the test object (static testing).
 When dynamic testing triggers a failure, debugging is concerned with finding causes of this failure
(defects), analyzing these causes, and eliminating them.
 The typical debugging process in this case involves:
 Reproduction of a failure
 Diagnosis (finding the root cause)
 Fixing the cause
 When static testing identifies a defect, debugging is concerned with removing it. There is no need for
reproduction or diagnosis, since static testing directly finds defects, and cannot cause failures
Testing and Debugging

TM
 Testing provides a cost-effective means of detecting defects. These defects can then be removed (by
debugging – a non-testing activity), so testing indirectly contributes to higher quality test objects.
 Testing provides a means of directly evaluating the quality of a test object at various stages in the SDLC.
 These measures are used as part of a larger project management activity, contributing to decisions to
move to the next stage of the SDLC, such as the release decision.
 Testing provides users with indirect representation on the development project. Testers ensure that their
understanding of users’ needs are considered throughout the development lifecycle.
 Testing may also be required to meet contractual or legal requirements, or to comply with regulatory
standards.
Testing’s Contribution to Success

TM
 While people often use the terms “testing” and “quality assurance” (QA)
interchangeably, testing and QA are not the same. Testing is a form of quality control
(QC).
 QC is a product-oriented, corrective approach that focuses on those activities
supporting the achievement of appropriate levels of quality. Testing is a major form
of quality control, while others include formal methods (model checking and proof of
correctness), simulation and prototyping.
 QA is a process-oriented, preventive approach that focuses on the implementation
and improvement of processes. It works on the basis that if a good process is
followed correctly, then it will generate a good product. QA applies to both the
development and testing processes, and is the responsibility of everyone on a
project.
 Test results are used by QA and QC. In QC they are used to fix defects, while in QA
they provide feedback on how well the development and test processes are
performing.
Quality Assurance and Quality Control

TM
 When humans do anything wrong unintentionally it is calls as “Mistake”, in programming it’s “Error”
 Human beings make errors (mistakes), which produce defects (faults, bugs), which in turn may result in
failures. Humans make errors for various reasons, such as time pressure, complexity of work products,
processes, infrastructure or interactions, or simply because they are tired or lack adequate training.
 A Defect is defined as deviation between expected and actual result
 Defects can be found in documentation, such as a requirements specification or a test script, in source
code, or in a supporting artifact such as a build file.
 A failure is an approach of finding defects.
 If a defect in code is executed, the system may fail to do what it should do, or do something it shouldn’t,
causing a failure.
Error, Defect, Failures and Root Causes

TM
 Errors and defects are not the only cause of failures. Failures can also be caused by environmental
conditions, such as when radiation or electromagnetic field cause defects in firmware.
 A root cause is a fundamental reason for the occurrence of a problem (e.g., a situation that leads to an
error). Root causes are identified through root cause analysis, which is typically performed when a failure
occurs or a defect is identified.
 It is believed that further similar failures or defects can be prevented or their frequency reduced by
addressing the root cause, such as by removing it.
Error, Defect, Failures and Root Causes

TM
Principles of Testing
• Testing shows presence of defects.
Principle 1
• Exhaustive testing is impossible.
Principle 2
• Early testing
Principle 3
• Defect clustering
Principle 4
• Tests Wears Out
Principle 5
• Testing is context dependent
Principle 6
• Absence-of-defect fallacy
Principle 7

TM
 Testing can show that defects are present in a system software, but no matter whatever count of defects
we find, at any point of time we can’t say there no more defects.
 Also to add to it, in case no defects are found, it’s not a proof of correctness.
Testing shows presence of defects, not there absence

TM
 Testing everything, which means all possible combination of inputs and preconditions is generally not
feasible to be conducted.
 As an alternate to exhaustive testing, risk analysis and priorities should be used to focus on testing efforts
Exhaustive Testing is Impossible

TM
 To find defects earlier or to prevents defects being introduced, testers must be involved as early as
possible in developments life cycle. Testing activities must be coordinated with corresponding
development activities.
 Testers are good contributor in reviews and must participate. This helps them understand the
requirements earlier and prepare test cases earlier in life cycle.
Early Testing Saves Time and Money

TM
 It is possible that the more defects are clustered in smaller modules compared to being distributed among
bigger and other modules.
 In this regards, a tester must consider and prepare proportional test cases to test such system.
Defects Cluster Together

TM
 If the same tests are repeated over and over again, eventually the same set of test cases will no longer help
find new defects.
 To overcome this “pesticide paradox” test cases need to be regularly reviewed and revised.
Tests Wear Out (Pesticide Paradox)

TM
 Testing is done differently in different context.
 Two different software are testing with different strategy.
Testing is Context Dependent

TM
 Meeting the requirement is equally important.
 Finding and fixing defect doesn’t help if the system built doesn’t fulfill the users’ need and expectations
Absence-of-Defects Fallacy

TM
 Testing is context dependent, but, at a high level, there are common sets of test activities without which
testing is less likely to achieve test objectives.
 These sets of test activities form a test process.
 The test process can be tailored to a given situation based on various factors. Which test activities are
included in this test process, how they are implemented, and when they occur is normally decided as part
of the test planning for the specific situation
Test Activities, Testware & Test Roles

TM
Test Planning
 Test planning consists of defining the test objectives and then selecting an approach that best achieves the
objectives within the constraints imposed by the overall context.
Test monitoring and control.
 Test monitoring involves the ongoing checking of all test activities and the comparison of actual progress
against the plan.
 Test control involves taking the corrective or guiding actions necessary to meet the objectives of testing.
Test Activities

TM
Test Analysis
 Test analysis includes analyzing the Test Basis to identify testable features and to define and prioritize
associated Test Conditions, together with the related risks and risk levels
 The test basis and the test objects are also evaluated to identify defects they may contain and to assess
their testability. Where the defects are related to contradictions, omissions, inconsistencies, ambiguities,
etc.
 Test analysis is often supported by the use of test techniques.
 Test analysis answers the question “what to test?” in terms of measurable coverage criteria.
Test Activities

TM
Test Design
 Test design includes elaborating the test conditions into Test Cases and other Testware. This activity
often involves the identification of coverage items, which serve as a guide to specify test case inputs. Test
techniques can be used to support this activity.
 Test design also includes defining the
 test data requirements,
 designing the test environment and
 identifying any other required infrastructure and tools.
 Test design answers the question “how to test?”.
Test Activities

TM
Test Implementation
 Test implementation includes creating or acquiring the testware necessary for test execution (e.g., test
data).
 Test cases can be organized into Test Procedures and are often assembled into Test Suites.
 Manual and automated test scripts are created.
 Test procedures are prioritized and arranged within a test execution schedule for efficient test execution
 The test environment is built and verified to be set up correctly.
Test Activities

TM
Test Execution
 Test execution includes running the tests in accordance with the test execution schedule (test runs).
 Test execution may be manual or automated.
 Test execution can take many forms, including continuous testing or pair testing sessions. Actual test
results are compared with the expected results.
 The test results are logged. Anomalies are analyzed to identify their likely causes. This analysis allows us
to report the anomalies based on the failures observed.
Test Activities

TM
Test Completion
 Test completion activities usually occur at project milestones (e.g., release, end of iteration, test level
completion) for any unresolved defects, change requests or product backlog items created.
 Any testware that may be useful in the future is identified and archived or handed over to the appropriate
teams.
 The test environment is shut down to an agreed state.
 The test activities are analyzed to identify lessons learned and improvements for future iterations,
releases, or projects.
 A test completion report is created and communicated to the stakeholders..
Test Activities

TM
Testing is not performed in isolation. Test activities are an integral part of the development processes carried out within an
organization. Testing is also funded by stakeholders and its final goal is to help fulfill the stakeholders’ business needs.
Therefore, the way the testing is carried out will depend on a number of contextual factors including:
 Stakeholders (needs, expectations, requirements, willingness to cooperate, etc.)
 Team members (skills, knowledge, level of experience, availability, training needs, etc.)
 Business domain (criticality of the test object, identified risks, market needs, specific legal regulations, etc.)
 Technical factors (type of software, product architecture, technology used, etc.)
 Project constraints (scope, time, budget, resources, etc.)
 Organizational factors (organizational structure, existing policies, practices used, etc.)
 Software development lifecycle (engineering practices, development methods, etc.)
 Tools (availability, usability, compliance, etc.)
These factors will have an impact on many test-related issues, including: test strategy, test techniques used, degree of test
automation, required level of coverage, level of detail of test documentation, reporting, etc.
Test Process in Context

TM
Testware is created as output work products from the test activities. There is a significant variation in how different
organizations produce, shape, name, organize and manage their work products.
Proper configuration management ensures consistency and integrity of work products. The following list of work products
is not exhaustive:
 Test planning work products include: test plan, test schedule, risk register, and entry and exit criteria. Risk register is
a list of risks together with risk likelihood, risk impact and information about risk mitigation. Test schedule, risk
register and entry and exit criteria are often a part of the test plan.
 Test monitoring and control work products include: test progress reports, documentation of control directives and
risk information.
 Test analysis work products include: (prioritized) test conditions (e.g., acceptance criteria, see section 4.5.2), and
defect reports regarding defects in the test basis (if not fixed directly).
Testware

TM
 Test design work products include: (prioritized) test cases, test charters, coverage items, test data requirements and
test environment requirements.
 Test implementation work products include: test procedures, automated test scripts, test suites, test data, test
execution schedule, and test environment elements. Examples of test environment elements include: stubs, drivers,
simulators, and service virtualizations.
 Test execution work products include: test logs, and defect reports
 Test completion work products include: test completion report action items for improvement of subsequent projects
or iterations, documented lessons learned, and change requests (e.g., as product backlog items).
Testware

TM
In order to implement effective test monitoring and control, it is important to establish and maintain traceability
throughout the test process between the test basis elements, testware associated with these elements (e.g., test conditions,
risks, test cases), test results, and detected defects.
Accurate traceability supports coverage evaluation, so it is very useful if measurable coverage criteria are defined in the test
basis. The coverage criteria can function as key performance indicators to drive the activities that show to what extent the
test objectives have been achieved. For example:
 Traceability of test cases to requirements can verify that the requirements are covered by test cases.
 Traceability of test results to risks can be used to evaluate the level of residual risk in a test object.
Traceability Between Test Basis & Testware

TM
In addition to evaluating coverage,
 Good traceability makes it possible to determine the impact of changes
 Facilitates test audits, and helps meet IT governance criteria.
 Good traceability also makes test progress and completion reports more easily understandable by including the status
of test basis elements.
 This can also assist in communicating the technical aspects of testing to stakeholders in an understable manner
 Traceability provides information to assess product quality, process capability, and project progress against business
goals.
Traceability Between Test Basis & Testware

TM
In this syllabus, two principal roles in testing are covered: a test management role and a testing role.
The activities and tasks assigned to these two roles depend on factors such as the project and product context, the skills of
the people in the roles, and the organization.
 The test management role takes overall responsibility for the test process, test team and leadership of the test activities.
 The test management role is mainly focused on the activities of test planning, test monitoring and control and test
completion. The way in which the test management role is carried out varies depending on the context.
 For example, in Agile software development, some of the test management tasks may be handled by the Agile team.
Tasks that span multiple teams or the entire organization may be performed by test managers outside of the
development team.
 The testing role takes overall responsibility for the engineering (technical) aspect of testing. The testing role is mainly
focused on the activities of test analysis, test design, test implementation and test execution.
 Different people may take on these roles at different times.
 For example, the test management role can be performed by a team leader, by a test manager, by a development
manager, etc. It is also possible for one person to take on the roles of testing and test management at the same time.
Roles in Testing

TM
Skill is the ability to do something well that comes from one’s knowledge, practice and aptitude. Good testers should
possess some essential skills to do their job well. Good testers should be effective team players and should be able to
perform testing on different levels of test independence.
Generic Skills Required for Testing
While being generic, the following skills are particularly relevant for testers:
 Testing knowledge (to increase effectiveness of testing, e.g., by using test techniques)
 Thoroughness, carefulness, curiosity, attention to details, being methodical (to identify defects, especially the ones that
are difficult to find)
 Good communication skills, active listening, being a team player (to interact effectively with all stakeholders, to convey
information to others, to be understood, and to report and discuss defects)
 Analytical thinking, critical thinking, creativity (to increase effectiveness of testing)
 Technical knowledge (to increase efficiency of testing, e.g., by using appropriate test tools)
 Domain knowledge (to be able to understand and to communicate with end users/business representatives) to take on
the roles of testing and test management at the same time.
Essential Skills and Good Practices in Testing

TM
 Testers are often the bearers of bad news. It is a common human trait to blame the bearer of bad news.
 This makes communication skills crucial for testers. Communicating test results may be perceived as criticism of the
product and of its author.
 Confirmation bias can make it difficult to accept information that disagrees with currently held beliefs.
 Some people may perceive testing as a destructive activity, even though it contributes greatly to project success and
product quality.
 To try to improve this view, information about defects and failures should be communicated in a constructive way.at the
same time.
Essential Skills and Good Practices in Testing

TM
 One of the important skills for a tester is the ability to work effectively in a team context and to contribute positively to
the team goals. The whole team approach – a practice coming from Extreme Programming – builds upon this skill.
 In the whole-team approach any team member with the necessary knowledge and skills can perform any task, and
everyone is responsible for quality.
 The team members share the same workspace (physical or virtual), as co-location facilitates communication and
interaction.
 The whole team approach improves team dynamics, enhances communication and collaboration within the team, and
creates synergy by allowing the various skill sets within the team to be leveraged for the benefit of the project.
 Testers work closely with other team members to ensure that the desired quality levels are achieved.
 This includes collaborating with business representatives to help them create suitable acceptance tests and working
with developers to agree on the test strategy and decide on test automation approaches.
 Testers can thus transfer testing knowledge to other team members and influence the development of the product.
 Depending on the context, the whole team approach may not always be appropriate. For instance, in some situations,
such as safety-critical, a high level of test independence may be needed.
Whole Team Approach

TM
 A certain degree of independence makes the tester more effective at finding defects due to differences between the
author’s and the tester’s cognitive biases.
 Work products can be tested by their author (no independence),
 by the author's peers from the same team (some independence),
 by testers from outside the author's team but within the organization (high independence),
 or by testers from outside the organization (very high independence).
 For most projects, it is usually best to carry out testing with multiple levels of independence (e.g., developers
performing component and component integration testing, test team performing system and system integration testing,
and business representatives performing acceptance testing).
Independence of Testing

TM
The main benefit of independence of testing is that
 independent testers are likely to recognize different kinds of failures and defects compared to developers because of
their different backgrounds, technical perspectives, and biases.
 Moreover, an independent tester can verify, challenge, or disprove assumptions made by stakeholders during
specification and implementation of the system.
However, there are also some drawbacks.
 Independent testers may be isolated from the development team, which may lead to a lack of collaboration,
communication problems, or an adversarial relationship with the development team.
 Developers may lose a sense of responsibility for quality.
 Independent testers may be seen as a bottleneck or be blamed for delays in release.
Independence of Testing

TM
1. Which of the following statements describe a valid test objective?
Answer Set
A. To prove that there are no unfixed defects in the system under test
B. To prove that there will be no failures after the implementation of the system into production
C. To reduce the risk level of the test object and to build confidence in the quality level
D. To verify that there are no untested combinations of inputs
Sample Questions

TM
2. You have been assigned as a tester to a team producing a new system incrementally. You have noticed that no
changes have been made to the existing regression test cases for several iterations and no new regression defects
were identified. Your manager is happy, but you are not.
Which testing principle explains your skepticism?
Answer Set
A. Tests wear out
B. Absence-of-errors fallacy
C. Defects cluster together
D. Exhaustive testing is impossible
Sample Questions

TM
3. Which of the following factors (i-v) have SIGNIFICANT influence on the test process?
I. The SDLC
II. The number of defects detected in previous projects
III. The identified product risks
IV. New regulatory requirements forcing formal white-box testing
V. The test environment setup
Answer Set
A. i, ii have significant influence
B. i, iii, iv have significant influence
C. ii, iv, v have significant influence
D. iii, v have significant influence
Sample Questions

Chapter 1 - Fundamentals of Testing V4.0

More Related Content

Chapter 1 - Fundamentals of Testing V4.0