ELEC5618 · Software Quality Engineering
Software Testing Techniques
Week 6 of University of Sydney ELEC5618 Software Quality Engineering covers the core testing techniques: defect testing versus validation testing, black-box design (equivalence partitioning, boundary-value analysis) and white-box / path testing, integration strategies (top-down, bottom-up, big-bang, sandwich) and object-oriented class testing. It introduces the Fagan inspection used in the lab and establishes the test-design vocabulary the test plan (next chapter) organises.
What this chapter covers
- 01Testing consumes ~40-50% of development effort; a good test targets undiscovered errors, a successful test uncovers one; exhaustive testing is impossible
- 02Component (unit) testing (developer's job) vs integration testing (independent team, from the system spec)
- 03Test data (inputs) vs test case (inputs + predicted outputs per the spec)
- 04Equivalence partitioning: partition inputs into classes where behaviour is equivalent; choose one case per partition
- 05Boundary-value analysis: test at partition boundaries {lo−1, lo, interior, hi, hi+1} where defects concentrate
- 06White-box / path testing: exercise all statements/branches; independent paths from the program flow graph
- 07Integration strategies: big-bang, top-down (stubs), bottom-up (drivers), hybrid/sandwich (both); stub = called module, driver = calling module
- 08OO class testing across three dimensions — attributes, methods (valid/boundary/invalid), state transitions — with Arrange-Act-Assert structure
Equivalence partitioning and boundary values for a quantity field
- +1Identify the equivalence partitions: P1 = quantity < 1 (invalid), P2 = 1 ≤ quantity ≤ 500 (valid), P3 = quantity > 500 (invalid). The program is expected to behave the same within each class.
- +1Pick one representative from each partition for equivalence coverage: e.g. 0 (P1, invalid), 250 (P2, valid interior), 600 (P3, invalid).
- +1Add boundary-value cases using {lo−1, lo, interior, hi, hi+1}: 0 (just below the lower bound, invalid), 1 (lower bound, valid), 250 (interior, valid), 500 (upper bound, valid), 501 (just above the upper bound, invalid).
- +1State the expected results: 0 → rejected; 1 → accepted; 250 → accepted; 500 → accepted; 501 → rejected. The boundary set catches the classic off-by-one errors at 1 and 500 that a mid-partition value alone would miss.
Key terms
- Equivalence partitioning
- A black-box technique that divides inputs (and outputs) into classes where the program is expected to behave equivalently, then tests one representative per class — reducing the number of cases without losing coverage of distinct behaviours.
- Boundary-value analysis
- Choosing test cases at the boundaries of equivalence partitions, {lo−1, lo, interior, hi, hi+1}, because defects (especially off-by-one errors) cluster at the edges of valid ranges.
- Component vs integration testing
- Component (unit) testing exercises individual components and is usually the developer's responsibility; integration testing exercises groups of components together, is run by an independent team, and derives its cases from the system specification and architecture.
- Integration strategies
- Big-bang (all modules at once, no stubs/drivers), top-down (highest modules first, stubs for lower ones), bottom-up (lowest modules first, drivers for higher callers) and hybrid/sandwich (both ends, stubs and drivers). The main difficulty they manage is localising errors.
- Stub vs driver
- A stub simulates a called (lower-level) module with hardcoded responses (top-down); a driver simulates a calling (higher-level) module by issuing the calls the real caller would (bottom-up).
- OO class testing dimensions
- Three dimensions for a class: attributes (getters/setters/defaults of each field), methods (each with valid, boundary and invalid inputs) and state (verify state transitions), written with clear naming and Arrange-Act-Assert structure.
Software Testing Techniques FAQ
What is the difference between equivalence partitioning and boundary-value analysis?
Equivalence partitioning splits the input space into classes that should behave the same and tests one value per class, cutting redundant cases. Boundary-value analysis then adds cases at the edges of those classes — just below, on, and just above each boundary — because defects cluster there. You normally use them together: partition first, then pick boundary values within and around each partition.
When do I use a stub versus a driver in integration testing?
A stub replaces a lower-level module that a component under test calls, returning canned data — you use stubs in top-down integration, testing high-level modules before the lower ones exist. A driver replaces a higher-level module that would call the component — you use drivers in bottom-up integration, testing foundational modules first and simulating their callers. A sandwich/hybrid approach uses both at once.
How do I test an object-oriented class thoroughly?
Cover three dimensions. Attributes: check getters, setters and default values of each field. Methods: test each with valid input, a boundary case and an invalid input. State: verify the object moves correctly between its states (e.g. Active → Frozen → Closed). Write self-contained tests with descriptive names, Arrange-Act-Assert structure and specific assertions rather than just checking a value is non-null.
Can AI help me design test cases for ELEC5618?
Yes. Sia can walk you through deriving equivalence partitions and boundary sets, choosing between integration strategies, and structuring an OO class-test suite across the three coverage dimensions. Use it to learn the design techniques; it does not do graded assessment, and the University of Sydney academic-integrity policy applies.
Exam move
Drill the black-box techniques until they are mechanical: for any range, write the partitions and the boundary set {lo−1, lo, interior, hi, hi+1} with expected results, because this is a reliable source of method marks. Learn the four integration strategies as a comparison table (start point, simulation needed — stubs or drivers, best-for) and be able to say stub = called module, driver = calling module without hesitation. For OO testing, memorise the three coverage dimensions (attributes, methods, state) and the test-quality rules (self-contained, descriptive naming, Arrange-Act-Assert, specific assertions). Keep the component-vs-integration distinction (who runs it and where the cases come from) crisp. Confirm the exam format on Canvas.
Working through Software Testing Techniques in ELEC5618? Sia is AskSia’s AI Software Engineering tutor — ask any ELEC5618 Software Testing Techniques question and get a clear, step-by-step explanation grounded in how ELEC5618 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
