Summary of "ISTQB-FL | 1.2 What is Testing ?"

Context / series info

This video is part of an ISTQB tutorial series (in Arabic). The instructor plans two videos per week, each covering a section of a chapter. Chapter 1 topics will be revisited in greater depth later in the series.

Core definition and scope of testing

Testing is more than just running software to find bugs. Execution is one activity within a broader testing process that includes planning, control, design, execution, reporting, and closure.

Testing covers the whole lifecycle of test activities, not only executing tests to observe faults.

Testing lifecycle activities

Planning and control
- Decide what to test, when, and how; set objectives and resources.
Test design
- Derive test cases from the test basis (requirements, specifications).
Test execution (dynamic testing)
- Run tests and observe actual behavior.
Test evaluation and reporting
- Compare actual results with expected results and inform stakeholders.
Test exit / closure
- Confirm exit criteria, capture lessons learned, finalize deliverables and documentation, and perform reviews (e.g., source-code reviews).

Key concepts and terminology

Test condition
- A specific requirement or behavior to be verified (example: “calculator adds correctly”).
Test case
- Concrete inputs, actions, and expected results used to verify a test condition. Examples include positive/negative numbers, extreme values (very large), and edge cases such as sums equal to zero.
Test basis
- Source information used to design tests (requirements, specifications). Test design must align with the test basis to avoid mismatches.
Dynamic vs. Static testing
- Dynamic testing: running the program and observing runtime behavior to find defects.
- Static testing: reviewing artifacts (code, documents) without executing the program.
Reporting and stakeholders
- Testers produce reports that give stakeholders enough information to decide whether to proceed, deliver, or delay the product.

Testing goals and types (high level)

Primary goals:

Find defects.
Support defect fixing (provide reproducible information).
Provide decision information to stakeholders (risk, readiness).
Prevent recurrence of defects by feeding lessons back into the lifecycle.

Types introduced:

Functional testing / defect-finding testing — target finding faults in functionality.
Acceptance testing — verify the product meets customer/user needs before handover.
Non-functional testing — e.g., performance, reliability; ensure dependability in operation.
Operational / maintenance testing — check behavior over time in production or after release.
Regression / retest — verify that fixes resolved defects and did not introduce new ones.

Roles and activities

Testers vs developers
- Testers typically find and report defects; developers fix them; testers retest and run regression tests. In small teams, roles may overlap.
Early testing involvement
- The earlier testing begins (as soon as requirements/design start), the better for catching problems and preventing recurrence.
COTS (Commercial Off-The-Shelf) products
- Acceptance and usage testing of purchased packages (e.g., Microsoft Office) should verify the package meets the organization’s needs in its intended usage context.

Decision-making and risks

Testing provides risk information: stakeholders weigh defect probability/impact, schedule, and budget to decide on release or further fixes.
Exit criteria: testing should stop when predefined criteria are met or when sufficient information exists for stakeholders to make an informed decision — not simply because resources are exhausted, especially for safety-critical systems.
Safety-critical systems: in high-risk domains (medical, automotive), releasing a product cannot be justified merely because time or money ran out.

Study / tutorial guidance

Chapter 1 topics will be revisited in depth later; practical items (test conditions, test cases, static/dynamic testing, lifecycle, types) will be expanded.
The series is positioned as an ISTQB exam study guide; viewers are encouraged to follow regularly and participate with comments or questions.

Main speakers / sources

Primary speaker: the ISTQB tutorial instructor (Arabic-speaking tutor, unnamed in the video).
Referenced roles/sources: testers, developers, stakeholders/sponsors (decision-makers), and the test team.