Unit 1: Testing principles and test management
Software Testing and Quality Assurance notes · PTU syllabus (BSIT602)
On this page
- Unit summary
- Errors, faults, defects and failures
- Levels of testing
- Integration testing approaches
- System, regression, alpha, beta and acceptance testing
- The software testing life cycle
- Test planning
- Black-box test design strategies
- Equivalence partitioning, boundary value analysis and other techniques
- White-box test adequacy criteria
- Defect tracking and analysis
- Key terms
- Quick revision
- Important questions
Unit summary
Testing finds defects before customers do, and test management keeps that effort organised. This unit covers errors, faults, defects and failures, the levels and types of testing, white-box and black-box testing, the testing life cycle, test planning, black-box design strategies — random testing, equivalence partitioning and boundary value analysis — white-box test adequacy criteria, and defect tracking and analysis.
After this unit you can
- Distinguish errors, faults, defects and failures
- Explain the levels and types of testing
- Plan tests and design black-box and white-box test cases
- Track and analyse defects
PTU syllabus topics
- Errors/faults/defects/failures
- unit/integration/system/regression/alpha/beta/acceptance testing
- functional/performance/recovery testing
- white-box and black-box testing
- testing life cycle
- test planning
- black-box design strategies (random testing, equivalence class partitioning, boundary value analysis)
- white-box test adequacy criteria
- defect tracking and analysis
- 1Error
A human mistake
- 2Fault (defect)
The mistake in code
- 3Failure
The system behaves wrongly when the fault runs
Topic 1
Errors, faults, defects and failures
- 1Error (mistake)
A human action producing an incorrect result — a developer misreads a requirement
- 2Fault (bug)
The incorrect step or code introduced — wrong condition in the program
- 3Defect
Any deviation from requirements found in a work product
- 4Failure
Observable incorrect behaviour when the faulty code runs — wrong fee calculated
- Not every fault causes a failure: the faulty code may never execute or may give correct output for most inputs. Testing reveals failures; debugging locates and removes faults.
Topic 2
Levels of testing
- Testing: executing a program to find errors; a good test case has a high chance of finding an undiscovered error. Testing shows the presence of defects, not their absence.
- Acceptance testing
Users confirm the system meets their needs
- System testing
The complete system against requirements
- Integration testing
Combined modules and their interfaces
- Unit testing
Individual modules
Basis
Requirements and inputs–outputs
Internal code and logic
Tester knows code?
No
Yes
Techniques
Equivalence partitioning, boundary value analysis
Statement, branch and path coverage
Done by
Testers, users
Developers
Topic 3
Integration testing approaches
Big bang
All modules combined at once
Simple; faults hard to locate
Top-down
Start from the main module, use stubs below
Early skeleton; many stubs
Bottom-up
Start from low-level modules, use drivers
Easy fault isolation; no early prototype
Sandwich
Top-down and bottom-up together
Balanced; more complex
Topic 4
System, regression, alpha, beta and acceptance testing
- System testing
- Complete integrated system against requirements
- Regression testing
- Re-running tests after changes to catch new faults
- Alpha testing
- Users test at the developer's site under observation
- Beta testing
- Real users test in their own environment
- Acceptance testing
- Customer decides whether to accept, using agreed criteria
Functional testing
Features behave as specified
Admission form saves a valid record and rejects invalid ones
Performance testing
Response time, throughput and resource use under load
Results page loads within 2 seconds for 5,000 users
Recovery testing
System recovers correctly after forced failure
Power cut during fee payment does not lose or double-charge the transaction
Topic 5
The software testing life cycle
- 1. Requirement analysis: Identify testable requirements
- 2. Test planning: Strategy, scope, effort, schedule, tools
- 3. Test case development: Write test cases and test data
- 4. Test environment set-up: Hardware, software, data
- 5. Test execution: Run tests and log defects
- 6. Test closure: Reports, metrics, lessons learnt
Topic 6
Test planning
- Test plan identifier and introduction
- Purpose and references
- Test items and features to be tested
- What will be tested
- Features not to be tested
- And why
- Approach
- Levels, types, techniques, tools
- Pass/fail criteria
- When a test passes; suspension and resumption criteria
- Deliverables
- Test cases, logs, defect reports, summary report
- Environment and responsibilities
- Set-up, people, training
- Schedule and risks
- Milestones, contingencies, approvals
Topic 7
Black-box test design strategies
- Random testing: inputs chosen at random from the input domain — cheap and unbiased but may miss important cases; useful with automated oracles (fuzz testing).
Topic 8
Equivalence partitioning, boundary value analysis and other techniques
Equivalence partitioning
Divide inputs into valid and invalid classes; test one value from each
Classes below 0, 0–100, above 100: test −5, 50, 120
Boundary value analysis
Errors cluster at edges; test at and around boundaries
−1, 0, 1, 99, 100, 101
Cause–effect graphing and decision tables
Map combinations of input conditions to actions
Fine rules for late returns
Graph-based testing
Model objects and relationships, test each link
Navigation between screens
- Black-box testing finds incorrect or missing functions, interface errors, data structure errors, performance and initialisation errors.
Example
Age field accepting 18–60: equivalence classes — below 18 (invalid), 18–60 (valid), above 60 (invalid); test 10, 35, 70. Boundary values: 17, 18, 19, 59, 60, 61.
Topic 9
White-box test adequacy criteria
- Adequacy criterion: a rule deciding when white-box testing is sufficient, measured as coverage.
- Statement coverage
Every statement executed at least once
- Branch (decision) coverage
Every branch of each decision taken both ways
- Condition coverage
Each condition in a decision evaluated true and false
- Multiple-condition coverage
All combinations of conditions
- Path coverage
Every independent path — basis path testing with V(G)
Example
if (a > 0 && b > 0) x = 1; — one test (a = 1, b = 1) gives statement coverage; adding (a = −1, b = 1) gives branch coverage; condition coverage also needs b false, e.g., (a = 1, b = −1).
- Data flow criteria: all-definitions, all-uses and all-du-paths track where variables are defined and used. Loop testing checks loops at zero, one, typical and maximum iterations.
Topic 10
Defect tracking and analysis
- 1. New: Logged by the tester
- 2. Assigned: Given to a developer
- 3. Open: Being fixed
- 4. Fixed: Change made
- 5. Retest: Tester verifies
- 6. Closed: Verified fixed — or Reopened if it persists
Meaning
Impact of the defect on the system
Urgency of fixing it
Set by
Tester
Product manager or lead
Example of high severity, low priority
Crash in a rarely used old report
—
Example of low severity, high priority
—
Spelling mistake in the college name on the home page
- Defect report contents: ID, title, steps to reproduce, expected and actual results, environment, severity, priority, screenshots, status. Tools: Jira, Bugzilla, Azure DevOps.
- Defect analysis: classify defects by type, phase and cause; use Pareto analysis and root cause analysis; measure defect density and removal efficiency to improve the process.
Key terms
- Fault
- Incorrect step or code in a program
- Failure
- Observable deviation from expected behaviour
- Test plan
- Document describing scope, approach, resources and schedule of testing
- Boundary value analysis
- Testing at and around input boundaries
- Branch coverage
- Every decision outcome exercised at least once
Quick revision
- Error → fault → defect → failure.
- Unit, integration, system, regression, alpha, beta, acceptance; functional, performance, recovery.
- STLC phases; IEEE 829 test plan contents.
- Random testing, equivalence partitioning, BVA.
- Statement, branch, condition, path coverage; defect life cycle; severity vs priority; defect analysis.
Important exam questions
Practice questions written to the PTU exam pattern for this unit's syllabus: short answers (Section A style) and long answers (Sections B and C style).
Short-answer questions
- Q1.Distinguish a fault and a failure.
- Q2.What is regression testing?
- Q3.Name the phases of the STLC.
- Q4.What is random testing?
- Q5.Distinguish statement and branch coverage.
- Q6.Distinguish severity and priority.
Long-answer questions
- Q1.Explain the levels and types of software testing.
- Q2.Explain the testing life cycle and test planning.
- Q3.Explain black-box test design strategies with examples.
- Q4.Explain white-box adequacy criteria and defect tracking.
Stuck on this unit?
Message SBS on WhatsApp for help with Software Testing and Quality Assurance, or to ask about studying B.Sc IT at Synetic.
