КАТЕРИНА АБЗЯТОВА - Certify with confidence: ISTQB Foundation 4.0. Common errors and Exam preparation tips

2. 2
Speaker:
Kateryna Abzyatova,
Senior Manual QA Engineer at Ciklum
● more than 12 years of professional experience,
working as a Manual QA engineer
● tested Desktop, Web, and Mobile applications
● passed 4 ISTQB certifications:
Foundations, Mobile, Agile tester
and Advanced Test Manager
● mentor for more than 3 years:
18 groups for ISTQB Foundation
(including 6 - based on 4.0)
● more than 100 interviews as a technical expert,
mostly for senior positions

3. 3
01
02
03
3
ISTQB certifications overview
Agenda
Materials
Preparation plans

4. 4
04
05
06
07
4
Most common tricky questions
Exam options
FAQ
Q&A

5. ISTQB
certifications
overview
01

6. 6

7. 7
Foundation Level (CTFL) v4.0
ISTQB Foundation 4.0

8. 8
What does obtaining the ISTQB
Foundation 4.0 certification provide?
ISTQB Foundation 4.0
Helps to understand basic
testing concepts and basic
terms
Increasing market value and
strengthening CV, especially for
customers from Europe to the US
Structure existing
knowledge and experience,
including for conducting
interviews
Increasing clients' trust in
competence and
professionalism
Achieve career goals within the
company (performance review, passing
the competency matrix - certification
covers many issues)

9. 9
CTFL 4.0:
• Fundamentals of testing
• Testing throughout the SDLC
• Static testing
• Test analysis and design
• Managing the test activities
• Test tools
CTFL 3.1:
• Fundamentals of testing
• Testing throughout the SDLC
• Static testing
• Test techniques
• Test management
• Tools support for testing
CTFL 3.1 VS. CTFL 4.0
CTFL 4.0:
ISTQB Foundation 4.0

10. Materials
02

11. 11
Resources - books
Agile book Foundation 3.1 book
Foundation 4.0 books
ISTQB Foundation 4.0

12. 12
Resources - tests
Tests
– https://www.udemy.com/course/istqb-foundation-level-ctfl-certification/ -
best course with 1000 questions
– https://istqb.patshala.com/tests/
– https://www.guru99.com/istqb.html
Syllabus and official exam samples
– https://www.istqb.org/certifications/certified-tester-foundation-level
NEW 3 examples added!
– https://www.istqb.org/certifications/agile-tester
ISTQB Foundation 4.0

13. 13
Resources - videos
Best courses on Udemy YouTube channel -
TM Square
Logo
ISTQB Foundation 4.0

14. Preparation plan
03

15. 15
Plan A and B
ISTQB Foundation 4.0
Plan A - Maximum
Read:
● Syllabus 4.0
● Syllabus 3.1
● Agile Syllabus
Bonus: Book
Tests:
● Udemy 1000+
(A, B, C, D included)
Plan B - Minimum
Read:
● Syllabus 4.0
● Syllabus 3.1
● Agile Syllabus - partly
(1.1.2, 1.1.3, 1.2.2, 1.2.3, 1.2.4, 1.2.5,
2.1.3, 2.1.4, 2.1.5, 2.2.1, 2.3, 3.1)
Tests:
● Only A, B, C, D

16. 16
Learning Objectives
ISTQB Foundation 4.0
https://glossary.istqb.org/

17. 17
K1
Remember
8
ISTQB Foundation 4.0
Cognitive Level of Knowledge
the candidate may be asked to recognize, remember, or recall a keyword
or concept mentioned in any of the six chapters
K2
Understand
24
K3
Apply
8

18. 18
Foundation:
• No. of Questions: 40
• Total Points: 40
• Passing Score: 26
• Exam Length (mins): 60
(+25% Non-Native Language)
Exam Structure
ISTQB Foundation 4.0

19. 19
ISTQB Foundation 4.0
Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6
K1 - 2 K1 - 2 K1 - 2 K1 - 0 K1 - 1 K1 - 1
K2 - 6 K2 - 4 K2 - 2 K2 - 6 K2 - 5 K2 - 1
K3 - 0 K3 - 0 K3 -0 K3 - 5 K3 - 3 K3 - 0
8 6 4 11 9 2
Distribution of questions by chapters
Plus K-Level

20. 20
ISTQB Foundation 4.0
The most effective process
Buy a voucher
(with second try)
Select Plan and
method
Read Materials
Watch videos with
more examples
Complete tests from
exams
Select a date and
take the exam :)

21. Most common
tricky questions
04

22. 22
1.2.3. Errors, Defects, Failures
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.
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. Defects in artifacts
produced earlier in the SDLC, if undetected, often lead to
defective artifacts later in the lifecycle.
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. Some defects will always result in a failure if executed, while others will only result in a failure in specific
circumstances, and some may never result in a failure.
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.

23. 23
1.3. Testing Principles
1 Testing shows the presence,
not the absence of defects
2 Exhaustive testing is impossible
3 Early testing saves time and
money 4 Defects cluster together
5 Tests wear out.
6 Testing is context dependent
7 Absence-of-defects fallacy

24. 24
1.4.5. Roles in Testing
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.
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.

25. 25
2.1.3. Testing as a Driver for Software
Development
TDD, ATDD and BDD are similar development approaches, where tests are defined as a means of directing
development. Each of these approaches implements the principle of early testing and follows a shift-left
approach, since the tests are defined before the code is written. They support an iterative development model.
Test-Driven Development
(TDD):
❖ Directs the coding through
test cases (instead of
extensive software
design)
❖ Tests are written first, then
the code is written to
satisfy the tests, and then
the tests and code are
refactored

26. 26
2.1.3. Testing as a Driver for Software
Development
Acceptance Test-Driven
Development (ATDD):
● Derives tests from
acceptance criteria as part
of the system design
process
● Tests are written before the
part of the application is
developed to satisfy the
tests

27. 27
2.1.3. Testing as a Driver for Software
Development
Behavior-Driven Development
(BDD):
● Expresses the desired behavior
of an application with test cases
written in a simple form of
natural language, which is easy
to understand by stakeholders –
usually using the
Given/When/Then format.
● Test cases are then
automatically translated into
executable tests
For all the above approaches, tests may persist as automated tests to ensure the code quality in future adaptions / refactoring.

28. 28
2.2.1. Test Levels
Test levels are distinguished by the following
non-exhaustive list of attributes, to avoid
overlapping of test activities:
● Test object
● Test objectives
● Test basis
● Defects and failures
● Approach and responsibilities

29. 29
2.2.2. Test Types
Black-box testing is specification-based and derives
tests from documentation external to the test object. The
main objective of black-box testing is checking the
system's behavior against its specifications.
White-box testing is structure-based and derives tests
from the system's implementation or internal structure
(e.g., code, architecture, work flows, and data flows). The
main objective of white-box testing is to cover the
underlying structure by the tests to the acceptable level.
All the four above mentioned test types can be applied to
all test levels, although the focus will be different at each
level. Different test techniques can be used to derive test
conditions and test cases for all the mentioned test types

30. 30
3.1.Static Testing Basics
In contrast to dynamic testing, in static testing the
software under test does not need to be executed.
Code, process specification, system architecture
specification or other work products are evaluated
through manual examination (e.g., reviews) or with
the help of a tool (e.g., static analysis).
Test objectives include improving quality, detecting
defects and assessing characteristics like readability,
completeness, correctness, testability and consistency.
Static testing can be applied for both verification and
validation.

31. 31
4.2.1. Equivalence Partitioning
Equivalence Partitioning (EP) divides data into partitions (known as equivalence partitions) based on
the expectation that all the elements of a given partition are to be processed in the same way by the test
object. The theory behind this technique is that if a test case, that tests one value from an equivalence
partition, detects a defect, this defect should also be detected by test cases that test any other value from
the same partition. Therefore, one test for each partition is sufficient.

32. 32
4.2.2. Boundary Value Analysis
Boundary Value Analysis (BVA) is a technique based on exercising the boundaries of equivalence partitions.
Therefore, BVA can only be used for ordered partitions.
The minimum and maximum values of a partition are its boundary values. In the case of BVA, if two elements
belong to the same partition, all elements between them must also belong to that partition.
BVA focuses on the boundary values of the partitions because developers are more likely to make errors with
these boundary values. Typical defects found by BVA are located where implemented boundaries are misplaced to
positions above or below their intended positions or are omitted altogether.

33. 33
4.2.3. Decision Table Testing
The strength of decision table testing is that it
provides a systematic approach to identify all the
combinations of conditions, some of which might
otherwise be overlooked. It also helps to find any
gaps or contradictions in the requirements. If
there are many conditions, exercising all the
decision rules may be time consuming, since the
number of rules grows exponentially with the
number of conditions. In such a case, to reduce
the number of rules that need to be exercised, a
minimized decision table or a risk based
approach may be used.

34. 34
4.2.4. State Transition Testing
A state transition diagram models the behavior of a
system by showing its possible states and valid state
transitions. A transition is initiated by an event, which
may be additionally qualified by a guard condition. The
transitions are assumed to be instantaneous and may
sometimes result in the software taking action.
The common transition labeling syntax is as follows:
“event [guard condition] / action”. Guard conditions and
actions can be omitted if they do not exist or are irrelevant
for the tester.

35. 35
4.3.White-Box Test Techniques
Because of their popularity and simplicity, this section focuses on
two code-related white-box test techniques:
● Statement testing
● Branch testing
There are more rigorous techniques that are used in some
safety-critical, mission-critical, or high-integrity
environments to achieve more thorough code coverage.
There are also white-box test techniques used in higher test
levels (e.g., API testing), or using coverage not related to code
(e.g., neuron coverage in neural network testing). These
techniques are not discussed in this syllabus.

36. Exam options
05

37. 37
Test Center FLEX (Remote)
ISTQB Foundation 4.0
Possible options:
Paper (Public)

38. 38
Disadvantages:
• Not available in every city
• Can be no appropriate day/time
• Hard to get an extra time
• For some centers need to wait for result
Advantages:
• No preparation: just come and start
• Dictionary available
• Whiteboard for notes
Test Center
ISTQB Foundation 4.0

39. 39
Disadvantages:
• Stable internet connection needed
• Should be a room with door and no interruptions
• Place preparation needed (all monitors should be
covered!)
• Clean paper not allowed for notes (only whiteboard)
Advantages:
• Available from anywhere
• Almost any day/time (even weekends)
• No need to go to other place
• Easy to get an extra time and second try
FLEX (Remote)
ISTQB Foundation 4.0

40. 40
What is required for FLEX
Desktop or laptop with
webcam and a
microphone
Google Chrome or
Microsoft Edge
Chromium browser (a
Chrome extension will
need to be installed)
Photo ID Tablet or smartphone
with a camera
01 02 03 04
Stable internet
connection
05
ISTQB Foundation 4.0

41. 41
Select exam
FLEX - https://isqi.org/en/
● Be careful and select correct
version
Test center -
https://home.pearsonvue.com/isqi
● CTFL_Syll2018 (v. 3.1)
● CTFL_Syll_4.0 (v. 4.0)
ISTQB Foundation 4.0

42. 42
Select all options at the same time

43. 43
Whiteboard for Flex
Don’t forget:
Writing on paper not
allowed from Home.
ISTQB Foundation 4.0

44. FAQ
06

45. 45
TOP of Frequently Asked Questions
about FLEX
– How to apply a promo code?
– Can I choose Ukraine while abroad?
– What to do if the Internet is lost?
– Is it enough to read only the Syllabus?
– How to find motivation for learning?
– Is only one option always correct?
– Can I use headphones?
– When will I know my results?
– Will I see the correct answers after the
exam?
– Should I talk to someone?
– Can I change my answer choice?
ISTQB Foundation 4.0

46. Q&A

47. Stay Updated, Stay Connected!
Registration
Kateryna Abzyatova
Linked In

48. Thank you!