Lecture Notes
1. FUNDMENTALS OF TESTING
1.1 What is testing?
- Money
- Time
- Business reputation
- Injury or Death 1.1.1 Test Objectives
- Finding defects & failures
* Testing is a set of activities - Prevent failures
* Misconception: - Validating user needs
- Testing is a process (7 steps) - Verifying requirements
- Dynamic & Static
- Validation & Verification 1.1.2 Testing & Debugging
defect
development defects testing debugging
report
1.2 Why is testing necessary? 1. Reproduce the failure retesting
- cost-effective 2. Diagnosis
- evaluates quality at different 3. Fix the cause
stages of the lifecycles
1.2.2 Testing & Quality Assurance 1.2.3 Errors, defects, failures & root cause
error
defect failure
QC /mistake
Testing
QA
root static dynamic
cause testing testing
product-oriented process-oriented
corrective preventive
1.3 Testing principles
Write your notes here
1. Tesing shows presence of defects not their absence
100% bug free
2. Exhaustive testing is impossible
3. Early testing saves time and money
4. Defects cluster together 80/20
5. Tests wear out
defect #1
Test defect #2 debugging retesting
defect #3
6. Testing is context dependent
7. Absence-of-defects fallacy
Verification is not enough
validation is also important
https://t.me/ISTQB_FL_TarekRoshdy
Lecture Notes
1.4 Test activities, Testware & Test roles
Activities Testware Test roles
1. Planning Test plan, Test schedule, Risk register Test Manager
2. Monitor & Control Test progress report Test Manager
3. Test Analysis Test conditions (prioritized) Tester 1.4.5
roles of
what to test testing 1.4.4 Bidirectional Traceability
4. Test Design Test cases Tester Test basis Testware
how to test
Requirements
5. Implementation Procedures, test suites Tester UI Testing
are we ready? Code
6. Execution Defect report Tester
SRS (product backlog) Test cases Defect
7. Completion Test completion report Test Manager
1.1 1. x x
1.
1.2 2. x
1.3 xxx 3. x
1.4
1.5 Essential skills:
1.5.1 General skills
bearers of bad news 1.5.2 whole team approach
- Test knowledge
- Curiosity criticism business:
- Attention to details Dev Tester - Acceptance tests
- Communication skills Confirmation
bias
- Analytical thinking developer:
- Technical knowledge Business - Automation
- Domain knowledge - Test strategy
1.5.3 Independence of testers
less independece More independece
communication objective
relationship different types
developer is responsible of failures
for quality
subjective Isolation
whole-team approach types of Communication
failures Conflicts
Developers lose sense of
responsibility for quality
Write your notes here
https://t.me/ISTQB_FL_TarekRoshdy
Lecture Notes
2. SOFTWARE DEVELOPMENT LIFECYCLE MODELS (SDLC)
Sequential Iterative Incremental
waterfall v-model spiral prototyping unified process
Development Approaches:
Agile lifecycle:
- kanban TDD (how) ATDD (why) BDD
- extreme programing xP code -focused acceptance Given
- scrum criteria
When
write tests write tests
Devops & Testing Then
code As a user I want to login
Development & operations write codes to access the app
ATDD A.C Given
refactor
- Treat both equally TDD When
Devops
Then
Dev Ops
Retrospectives:
Shift-left early testing - What was successful
- Review requirements - What was not successful
- Review code - How to incorporate the improvements
- Write test cases before code 2.2 Test levels & Test types
- Static analysis Black-box testing:
Requirements
Test levels: component testing
l oper input output
deve
Mobile component integration 2+2 4
testing
Version ster
te
system testing White-box testing:
Architecture
Web system integration
Version testing
input output
Acceptance Testing
- users Confirmation & Regression:
- product owner defect Retesting
- business analyst Regression
Test types: M1 M2 M3
Functional testing: Non-functional testing: Maintenance testing:
yes
what the test object does How well the system behaves planned releases
- completness no - performance unplanned releases (hot fixes)
- correctness - usability Triggers for maintenance:
- appropriateness - security - modification
- upgrades or migration
- retirement
https://t.me/ISTQB_FL_TarekRoshdy
Lecture Notes
3. STATIC TESTING Reviews: any work product
Static Analysis
Static testing finds defects Code
Dynamic testing finds failure ّ I DE
warning errors
ct
Review process: Review types: dete lies
informal a
anom
Planning identify work product & scope review
er
lead or
t h
= au ified
Review initiation prepare for review walkthrough l l y qual
nic a rs
tech reviewe
y
led b tor
Individual review create anomalies Technical e r a
mod
review find m
imu
Communication & Analysis review anomalies max er of
b
num alies
Inspection an mo
Fixing & Reporting
Roles & Responsibilities :- Reviews:
Manager Author Moderator Scribe Reviewer Review leader
- Decides - Create work product - Mediation - Records - Review take overall
- Provides resources - Fix work product -Time Management decisions work product responsibility
Success factor for reviews:
concentration reviewers
Small chunk
provide feedback author
https://t.me/ISTQB_FL_TarekRoshdy
Lecture Notes
4. TEST ANALYSIS AND DESIGN
4) State-transition testing:
small number Achieve highest
of test cases coverage possible er tra
te pow n Car nsi
Test techniques sta o mo tio
n
on v
1. Black box techniques (specification-based) to e
Car D
1) Equivalence partitioning (EP)
15 off
5 Car
10 moves
pr bra
on
2) Boundary-value analysis:
es ke
Car
s
s
pres ke
stop ra
10 11 10 11 on b
*two point BVA
* all-states coverage (4 states)
9 10 11 10 11 12 * all valid-transitions coverage (4
* 10 , 11
9, 10, 11, 12 transitions)
No *three point BVA * all transitions coverage
Discount
discount
3) Decision-table testing: 4 table rules
1. Previous experience Y/N
2. Are you certified Y/N
Conditions 1 2 3 4
2. White-box techniques 2
Previous Y Y N N
Statement coverage: experience
1. 100% SC 7
Certified Y N Y N
1. if X > 5 Actions
3.
Get
4. else discount
5. Go to basic
Action course
+ Branch coverage
1. 7 DC 3. Experience-based techniques
1. if X > 5 1) Error guessing:
3. 3 SC Fault attack
4. else else 2) Exploratory testing:
5. Analysis
collaboration-based test approaches: Execute Design
collaborative user-story writing:
3C Test Session-based
charter SBTM
card conversation confirmation 3) Checklist-boxed testing:
senario-oriented
how software acceptance Given
When
Are all redirects
working?
will be used criteria rule-oriented Then
ATDD Acceptance test-driven development
user story write
Acceptance tests code
might be using
automated
TDD
1. positive tests https://t.me/ISTQB_FL_TarekRoshdy
2. negative tests
3. non-functional tests
Lecture Notes
5. TEST MANAGEMENT
Test planning Test plan
- schedules
- test activities
- communication Release planning & iteration planning:
- assumptions & cost reviews
- risk register
- budget
- test approches
Entry criteria & Exit criteria:
Entry criteria Exit criteria Release Iteration
(DOR) (DOD) writing testable break down user stories
user stories into testing tasks
Code is All interfaces
checked in tested
Integration
Static analysis System testing is ready Test case prioritization
Done testing
No blockers risk coverage requirement
100% BC -based -based -based
Coverage achieved
high risk highest
Estimation techniques: additional
medium -coverage
risk
metrics expert
based based low risk
1) Estimation Based on Ratios:
5 developers 15 developers 100 hrs dev 10 hrs testing
2 testers 6 testers 20 hrs dev 2 hrs testing
2) Extrapolation: 3) Wideband Delphi: (Planning poker)
experts makes estimations in isolation
12 Test pyramid
5 10 20
UI 1 0 %
4) Three-point estimates tests
O=2
M=5 O + 4M + P 2 + 5 X 4 + 30 = 52 30
%
E= = = 8.667 Service
P = 30 6 6 6 testing
30 - 2 28 %
Estimate = 8.667 +-4.67 60
SD =
6 = 6 = 4.67 +- Unit testing
https://t.me/ISTQB_FL_TarekRoshdy
Lecture Notes
Testing quadrants:
- business - business
- support - critique
Q2 Q3
Functional exploratory
UAT
- technology - technology
Q1 Q4 product risks
- support - critique Risks types:
project risks
Component Non-functional
tests
Risk management:
Configuration management:
Risk identification
likelihood testware uniquely identified
Risk assessment risk analysis
impact (test items)
version controlled
Risk mitigation
Risk control tracked for changes
Risk monitoring related to other configuration items
Defect management:
Monitoring, control & completion
gathering corrective - ID - Actual result
information actions - Title - Severity
test - Date - Priority
te st pr og re ss re po rt completion - Test object - Status
- Steps to reproduce
test completion - Expected result
report
Write your notes here
https://t.me/ISTQB_FL_TarekRoshdy
Lecture Notes
6. TEST TOOLS
- Management tools
- Static testing tools
- Design & Implementation
- Execution & Coverage tools
- Non-Functional test tools
- DevOps tools
- Collaboration tools
- Scalability & Deployment
Benefits of Automation Risks of Automation
- Unrealistic expectations
- Reducing time
- Relying on tool too much
- Prevention of human errors
- Vendor problems
- Easier access to information
- Open-source tools
Service
testing
https://t.me/ISTQB_FL_TarekRoshdy
