Chapter 1 — All learning objectives
1.1 What is Testing?
1.2 Why is Testing Necessary?
1.3 Testing Principles
1.4 Test Activities, Testware and Test Roles
1.5 Essential Skills and Good Practices
K-level legend
| Level | Action | Exam style |
|---|---|---|
| K1 | Remember / Recall | "Which of the following IS a test objective?" |
| K2 | Understand / Explain / Differentiate | "Which statement BEST describes…?" |
1.1 What is Testing?
📌 Definition
🎯 Typical test objectives — mnemonic: F C R V L I C V
| Letter | Objective | Meaning |
|---|---|---|
| F | Find defects | Evaluating work products (requirements, code, designs) by causing failures and finding defects |
| C | Coverage | Ensuring required coverage of a test object |
| R | Risk reduction | Reducing the risk level of inadequate software quality |
| V | Verification | Verifying whether specified requirements have been fulfilled |
| L | Legal compliance | Verifying the test object complies with contractual, legal, and regulatory requirements |
| I | Information to stakeholders | Providing information to allow informed decisions |
| C | Confidence building | Building confidence in the quality of the test object |
| V | Validation | Validating that the test object works as expected by stakeholders |
🔍 Verification vs Validation
Verification ✅
Are we building the product right?
Checks if software meets specified requirements.
e.g., "Does the login page match the design spec?"
Validation ✅
Are we building the right product?
Checks if software meets user needs.
e.g., "Does the login page satisfy what users actually need?"
⚡ Testing vs Debugging
| Aspect | Testing | Debugging |
|---|---|---|
| Who | Tester | Developer |
| Goal | Find defects / failures | Identify cause of defects and fix them |
| Output | Defect report | Fixed code |
| Static testing | Directly finds defects | Only remove the defect (no reproduction needed) |
| Dynamic testing | Triggers failures | Reproduce → Diagnose → Fix |
Debugging process (dynamic testing):
📦 Static vs Dynamic Testing
Static Testing
No execution. Uses reviews and static analysis tools.
Finds defects directly.
e.g., Code reviews, SonarQube analysis, requirement reviews
Dynamic Testing
Requires executing the software. Observes actual output vs expected.
Finds failures → then debugging finds defects.
e.g., Running automated test cases, manual UI testing
1.2 Why is Testing Necessary?
🌍 Software in Daily Life
Software is essential in banking, communication, healthcare, aviation, and almost every aspect of life. Faulty software can cause financial loss, wasted time, loss of reputation, and in extreme cases injury or death.
🎯 Testing's contributions to success
- Cost-effective defect detection — finding defects early is cheapest; after detection, debugging removes them
- Evaluates quality at different stages of the SDLC
- Supports management decisions — test metrics help decide whether to release or move to next phase
- Represents user needs — testers simulate real users (cheaper than involving real users)
- Meets legal & regulatory requirements — contracts, compliance, safety standards
🔄 Testing vs Quality Assurance (QA)
| Aspect | Testing (QC) | QA |
|---|---|---|
| Approach | Corrective | Preventive |
| Focus | Product-oriented | Process-oriented |
| Goal | Achieve appropriate quality levels | Implement & improve processes |
| Responsibility | Test team primarily | Everyone on the project |
| Uses test results to | Fix defects | Evaluate process performance |
Quality Control (QC) includes:
1.2.3 Error → Defect → Failure → Root Cause
🔗 The chain
Error
Defect (Bug/Fault)
Failure
| Term | Also called | Definition | Example |
|---|---|---|---|
| Error | Mistake | A human action that produces an incorrect result | Developer types < instead of <= |
| Defect | Bug, Fault | A flaw in a work product that can cause failure | Wrong condition in code |
| Failure | — | Defect executed → system does not perform as expected | System crashes on valid input |
| Root cause | — | The fundamental reason behind a defect or failure | Poor training → coding error |
🧠 Causes of human errors
📌 Key facts about defects & failures
- Defects can exist in any work product — documentation, requirements, test scripts, source code, build files
- Early-stage defects (requirements) can propagate to later stages if not caught
- Not all defects cause failures — some only fail under specific conditions; some never fail
- Failures can also be caused by environmental factors — radiation, electromagnetic fields (hardware/firmware)
📝 Mnemonic for this section
1.3 Seven Testing Principles
Mnemonic: "Please Examine Early Tests, Defects Tend to Accumulate"
📐 All 7 principles
Testing shows Presence of defects, not absence
Testing can prove defects exist ✅
Cannot prove no defects exist ❌
Testing only reduces the probability of defects.
Exam: "Testing proves software is correct" → FALSE
Exhaustive testing is impossible
Testing all possible inputs/conditions is not feasible (except trivial systems).
Use: test techniques, prioritization, risk-based testing.
Exam: Focus on important and high-risk areas
Early testing saves time and money
Finding defects early = lower cost, less rework.
Both static & dynamic testing should start as early as possible in SDLC.
Exam: Shift-left testing concept
Defects cluster together
Most defects found in few modules (Pareto Principle / 80-20 rule).
Focus testing on defect-prone areas.
Exam: Explains why risk-based testing is effective
Tests wear out
Repeating the same tests finds fewer new defects over time.
Solution: update test cases, add new tests.
Exception: useful in regression testing (automation).
Exam: Why test cases should be updated regularly
Testing is context dependent
Testing approach differs by software type, industry, risks.
Banking software ≠ Gaming software.
No single universal testing method.
Exam: No one-size-fits-all approach
Absence-of-defects fallacy
Even if no defects found and requirements met — software may still fail user expectations or business goals.
Validation is also important, not just verification.
Exam: "No bugs found = product is good" → FALSE
⚡ Quick reference table
| # | Principle | Key message |
|---|---|---|
| 1 | Presence not absence | Cannot prove zero defects |
| 2 | Exhaustive impossible | Use risk & prioritisation |
| 3 | Early testing | Earlier = cheaper to fix |
| 4 | Defect clustering | 80/20 rule — focus on risky modules |
| 5 | Tests wear out | Update tests regularly |
| 6 | Context dependent | No universal approach |
| 7 | Absence fallacy | No bugs ≠ product is good |
1.4.1 & 1.4.2 Test Activities & Context
🔄 Seven test activities
Activities may be sequential, iterative, or parallel depending on context.
📋 Each activity explained
Test Planning — "What are the goals?"
Define test objectives, select best testing approach within constraints (time, cost, resources). Decides what, how, and when to test.
Test Monitoring & Control — "Are we on track?"
Monitoring: continuously compare actual vs planned progress.
Control: take corrective actions to meet objectives (re-prioritize, add resources).
Test Analysis — "What to test?"
Study test basis (requirements, specs). Identify testable features. Define & prioritise test conditions based on risk. Find testability issues.
Test Design — "How to test?"
Convert test conditions into test cases. Identify coverage items. Define test data requirements, test environment, tools and infrastructure.
Test Implementation — "Prepare for testing"
Create/acquire test data & scripts. Organise test cases → test procedures → test suites. Set up test environment. Prioritise execution order.
Test Execution — "Run tests"
Execute test cases (manually or automated). Compare actual vs expected results. Log test results. Identify failures & report defects. Includes continuous testing & pair testing.
Test Completion — "Wrap up & improve"
Report unresolved defects. Archive testware. Shut down test environment. Analyse lessons learned. Create test completion report. Improve future testing.
🌐 Test process in context (1.4.2)
Testing is not isolated — it is funded by stakeholders and must fulfil business needs. These context factors affect test strategy, techniques, automation level, coverage, and reporting:
| Factor | Examples |
|---|---|
| Stakeholders | Needs, expectations, requirements, cooperation level |
| Team members | Skills, knowledge, experience, availability, training needs |
| Business domain | Criticality (banking vs gaming), risks, legal regulations |
| Technical factors | Software type, architecture, technology stack |
| Project constraints | Scope, time, budget, resources |
| Organizational factors | Company structure, policies, existing practices |
| SDLC | Agile, Waterfall, DevOps — affects when/how testing occurs |
| Tools | Availability, usability, compatibility |
1.4.3 Testware & 1.4.4 Traceability
📦 What is testware?
Managed using configuration management to ensure consistency and integrity.
📋 Testware by activity
| Activity | Work products (testware) |
|---|---|
| Test Planning | Test plan, test strategy, risk register (risks + likelihood + impact + mitigation) |
| Monitoring & Control | Test progress reports, control directives, risk-related information |
| Test Analysis | Test conditions (prioritised), acceptance criteria, defect reports (in test basis) |
| Test Design | Test cases, test charters, coverage items, test data requirements, environment requirements |
| Test Implementation | Test procedures, test scripts (manual & automated), test suites, test data, execution schedule, stubs/drivers/simulators |
| Test Execution | Test logs, defect reports |
| Test Completion | Test completion report, lessons learned, improvement actions, change requests |
🔗 Traceability (1.4.4)
Benefits of traceability:
- Coverage evaluation — confirms all features are tested
- Impact analysis — identifies which tests are affected by changes
- Audit support — makes reviews and audits easier
- IT governance compliance — meets organisational and regulatory standards
- Better reporting — test progress and completion reports are clearer for stakeholders
Coverage as KPI:
Coverage criteria act as Key Performance Indicators (KPIs) — measurable values that evaluate how effectively test objectives are being achieved.
Types of traceability:
1.4.5 Roles in Testing
👥 Two principal roles
👔 Test Management Role
Focus: Management & leadership
Activities:
• Test planning
• Test monitoring
• Test control
• Test completion
In Agile: tasks may be shared by whole team
Large projects: dedicated test managers
🔧 Testing Role (Technical)
Focus: Technical/engineering aspects
Activities:
• Test analysis
• Test design
• Test implementation
• Test execution
One person can perform both roles depending on context.
🏢 Tester interactions with other roles
| Interacts with | About |
|---|---|
| Developer | Test strategy, automation approach, fixing bugs |
| Business Analyst | Clarify and understand requirements |
| Project Manager | Risk assessment, current testing status |
| Client | Review requirements, UAT |
| DevOps | CI/CD pipeline, environment setup and deployment |
📋 Roles & testware ownership
| Role | Prepares / owns | Reviews |
|---|---|---|
| Test Manager | Test plan, test strategy | Test summary report, risk reports |
| Test Analyst / QA | Test conditions, test cases, test data | Requirements, RTM |
| Automation Engineer | Test scripts, automation suites | — |
| Tester / QA Tester | Test logs, defect reports | — |
| Developer | Unit tests, fixes | Defect reports, technical test cases |
| Business Analyst | Requirements, business rules | Test cases, RTM |
| Project Manager | — | Test plan, progress & summary reports |
1.5.1 Generic Skills & 1.5.2 Whole Team Approach
🧠 Generic skills required for testing
📘 Testing knowledge
Understanding concepts and techniques. Improves testing effectiveness.
e.g., Knows BVA → finds off-by-one error at ATM limit
🔎 Personal qualities
Thoroughness, carefulness, curiosity, attention to detail, methodical approach.
e.g., Notices "₹" symbol missing on price display
💬 Communication skills
Clear communication, active listening, teamwork. Report defects clearly and constructively.
✅ "Login fails when password > 20 chars" not ❌ "Login is broken"
🧩 Thinking skills
Analytical thinking, critical thinking, creativity.
e.g., Login fails on slow internet → identifies network delay as root cause
⚙️ Technical knowledge
Understanding tools and technologies. Increases testing efficiency.
e.g., Uses Selenium to run 100 test cases automatically
🏦 Domain knowledge
Knowledge of business domain (banking, healthcare). Ensures correctness of test scenarios.
e.g., Knows interest calculation rules → finds calculation bug
👨👩👧👦 Whole Team Approach (1.5.2)
✅ Advantages
- Improves team dynamics
- Enhances communication & collaboration
- Creates synergy by leveraging all skill sets
- Transfers testing knowledge across team
- Testers help BAs create acceptance tests
- Shared workspace (physical or virtual) facilitates interaction
⚠️ Not always appropriate when:
- High independence needed (e.g., safety-critical systems)
- Lack of testing skills across the team
- Time and cost constraints prevent cross-training
- Risk of bias — fresh perspective may be needed
Team development stages (Tuckman):
Roles unclear
Disagreements
Agreement
Smooth execution
1.5.3 Independence of Testing
📌 What is independence?
Independence ≠ replacement of developer testing. Developers can still find many defects in their own code — but an independent tester thinks differently and finds different types of defects.
📊 Levels of independence
| Level | Tested by | Independence | Example |
|---|---|---|---|
| 1 | Author (developer) | None | Developer tests own code |
| 2 | Peers (same team) | Some | Code review by teammate |
| 3 | Testers from another team | High | Separate QA team |
| 4 | External testers | Very high | Outside organisation |
⚖️ Benefits vs Drawbacks
✅ Benefits
- Finds different types of defects
- Provides fresh perspective
- Can verify, challenge, and disprove assumptions
- Reduces bias from cognitive blindness
⚠️ Drawbacks
- Poor communication between testers & developers
- Adversarial relationship / conflicts
- Developers may lose responsibility for quality
- Testers seen as bottlenecks or cause of delays
Requirements Traceability Matrix (RTM)
📋 What is RTM?
🗂️ Example RTM
| Req ID | Requirement | Test Case ID | Test Description | Result | Defect ID |
|---|---|---|---|---|---|
| R1 | Login with valid credentials | TC1 | Verify login with correct username & password | ✅ Pass | — |
| R2 | Login with invalid credentials | TC2 | Verify error message on wrong login | ❌ Fail | D1 |
| R3 | Password reset | TC3 | Verify password reset functionality | ✅ Pass | — |
| R4 | Logout functionality | TC4 | Verify user can log out | ❌ Fail | D2 |
✅ Key points for exam
- Ensures 100% requirement coverage
- Helps in impact analysis — when requirements change, know which tests are affected
- Supports defect tracking — links bugs back to requirements
- Used in test planning, monitoring, and reporting
Forward traceability
Requirement → Test Case
Are all requirements covered?
Backward traceability
Test Case → Requirement
Is every test case justified?
Bidirectional
Both directions.
Best practice for complete coverage.
Key definitions & exam traps
📖 Essential definitions
| Term | Definition |
|---|---|
| Test object | The actual application, system, or module being tested |
| Test basis | Source of information used to create test cases (requirements, design docs, user stories) |
| Test condition | A specific aspect or feature to be tested — derived from the test basis |
| Testware | Everything a tester creates to test the application (plans, cases, scripts, data, reports, logs) |
| Traceability | Link between requirements, test cases, results, and defects — ensures coverage and supports monitoring |
| Error | A human mistake that produces an incorrect result |
| Defect | A flaw in a work product (also: bug, fault) — caused by an error |
| Failure | When a defect is executed and the system does not perform as expected |
| Root cause | The fundamental reason behind a defect or failure |
| Verification | Are we building the product right? (meets specs) |
| Validation | Are we building the right product? (meets user needs) |
| Debugging | The process of finding, analysing, and fixing defects — done by developers |
| Confirmation testing | Testing after a fix to verify the defect is resolved |
| Regression testing | Testing after a fix to verify nothing else was broken |
| Continuous testing | Running automated tests continuously at every stage of CI/CD pipeline |
| Pair testing | Two people work together on testing the application |
| Whole team approach | Everyone on the team is responsible for quality (from XP/Agile) |
🚨 Common exam traps
Trap 2: "Testing and QA are the same" → FALSE — Testing = corrective/product-oriented; QA = preventive/process-oriented
Trap 3: "Debugging is part of testing" → FALSE — Debugging is done by developers; testing finds defects/failures
Trap 4: "Exhaustive testing is achievable with enough time" → FALSE — Principle 2 says it is impossible
Trap 5: "If no defects are found, the software is ready" → FALSE — Absence-of-defects fallacy (Principle 7)
Trap 6: "Independence of testing eliminates all defects" → FALSE — it reduces bias and finds different defects, but has drawbacks
Trap 7: "Test monitoring and test control are the same activity" → FALSE — monitoring = checking progress; control = taking corrective action
Trap 8: "The whole team approach is always appropriate" → FALSE — not suitable for safety-critical systems needing high independence
⚡ Ultra-quick revision
| Topic | One-liner |
|---|---|
| Test objectives | F C R V L I C V — Find, Coverage, Risk, Verify, Legal, Inform, Confidence, Validate |
| Error→Defect→Failure | Human mistake → code flaw → system misbehaviour |
| 7 principles | P E E T T D A — Presence, Exhaustive, Early, Tired tests, Defect cluster, Context, Absence fallacy |
| Test activities | Plan → Monitor/Control → Analyse → Design → Implement → Execute → Complete |
| Testware | Everything created during testing — plans, cases, scripts, data, logs, reports |
| Traceability | Req ↔ Test Case ↔ Result ↔ Defect — ensures coverage, supports audits |
| Testing vs Debugging | Testing finds defects; debugging fixes them |
| QC vs QA | QC = corrective/product; QA = preventive/process |
| Independence levels | None → Peer → Another team → External |
| Whole team approach | Everyone responsible for quality (from XP) — not always appropriate |