ELEC5618 · Software Quality Engineering
The Software Test Plan
Week 7 of University of Sydney ELEC5618 Software Quality Engineering assembles a software test plan: its scope, the items and features to be tested, the approach, pass/fail criteria, deliverables, environment and schedule, and the types of tests it coordinates (unit, integration, system, acceptance). It links planning back to the Software Quality Plan and forward to the tooling week, and maps test levels onto the development stages via the V-model. This is a Week-7 milestone-check week and the week the mid-term quiz question is released.
What this chapter covers
- 01Software Test Plan (STP): objectives, scope, approach and focus of the testing effort; should be organisation-wide and start alongside the requirements
- 02STP structure: scope of tests · testing environment · test details (per test) · test schedule
- 03IEEE 829 key contents (20 items): test items, features to/not to be tested, approach, item pass/fail criteria, suspension/resumption, deliverables, staffing, schedule, risks, approvals
- 04Types of tests: functional, integration, user/business acceptance (UAT), performance
- 05Test levels and the V-model: unit ↔ component design, integration ↔ architecture, system ↔ requirements, acceptance ↔ user needs
- 06Test-case template (10 elements): title, type, purpose, prerequisite, input data, steps, output (expected/actual), exit criteria, recommendations, notes
- 07Testability and dependency injection: inject collaborators so tests can substitute a stub
- 08Requirements Traceability Matrix (RTM): map each requirement to the tests that verify it
Writing a test case and placing it in the V-model
- +1Fill the core template slots. Title: 'Transfer rejected on insufficient funds'. Type: functional (black-box). Purpose: verify the balance check blocks an over-limit transfer. Prerequisite: user is logged in and owns a source account with a known small balance.
- +1Input data / steps: source balance = 50; attempt to transfer 200 to another owned account; submit. Expected output: transfer is rejected with an 'insufficient funds' message and both balances are unchanged. Actual output: recorded at run time.
- +1Exit criteria (pass/fail): PASS if the transfer is refused and balances are unchanged; FAIL otherwise. Add a note that the sufficient-funds path is a separate case.
- +1Test level and V-model: this exercises a business rule spanning the transfer feature, so it is a system (or acceptance) test rather than a unit test. On the V-model it maps to the requirements/user-needs level on the right-hand (verification) arm, opposite the requirements-definition stage on the left.
Key terms
- Software Test Plan (STP)
- A document describing the objectives, scope, approach and focus of a testing effort — the items to test, the levels, the sequence, the strategy and the environment. It should be organisation-wide and begin at the same time as the requirements and project plan.
- IEEE 829
- The standard for software and system test documentation. Its key test-plan contents include test items, features to and not to be tested, the approach, item pass/fail criteria, suspension/resumption criteria, deliverables, staffing, schedule, risks and approvals.
- Test levels
- Unit (single component), integration (components together), system (the whole system against requirements) and acceptance (against user/business needs). Integration confirms components work together technically; acceptance confirms they work per the business scenario.
- V-model
- A lifecycle model that pairs each development stage with a testing level: unit tests opposite component design, integration tests opposite architecture, system tests opposite requirements, and acceptance tests opposite user needs.
- Test-case template
- The 10-element structure of a test case: title, type of test, purpose, prerequisite, input data/entry criteria, steps, output (expected and actual), exit (pass/fail) criteria, recommendations and notes. A test case = inputs plus predicted outputs.
- Requirements Traceability Matrix (RTM)
- A matrix mapping each requirement (SRS-nn) to the tests (Test-nn) that verify it, so every requirement is individually tested and any missing verification link is visible.
The Software Test Plan FAQ
What goes into a software test plan?
Scope (which package and basis documents), the testing environment (sites, hardware, people, training), the test details per test (identification, objective, cross-references, class and level, case requirements, data to record) and the schedule (time for preparation, testing, correction and regression). The IEEE 829 key contents add items such as features to and not to be tested, pass/fail and suspension criteria, deliverables, staffing, risks and approvals. A good plan is organisation-wide and starts alongside the requirements.
What are the different test levels and how does the V-model relate them?
Unit tests exercise a single component, integration tests exercise components together, system tests check the whole system against its requirements, and acceptance tests check it against user/business needs. The V-model lines each level up against a development stage on the opposite arm — unit against component design, integration against architecture, system against requirements, acceptance against user needs — so every stage has a matching verification activity.
What makes a complete test case?
A test case is inputs plus predicted outputs, so it must state the expected result, not just the input (that would be test data). The template captures title, type, purpose, prerequisite, input data, steps, expected and actual output, a PASS/FAIL exit criterion, and notes. The pass/fail criterion is what turns an execution into a decision.
Can AI help me write a test plan or test cases?
Yes. Sia can walk through the STP structure and the IEEE 829 contents, help you complete a test-case template with a proper pass/fail criterion, and place a test at the right level on the V-model. Use it to learn the structure; it does not do graded assessment, and the University of Sydney academic-integrity policy applies.
Exam move
Memorise two structures you can reproduce on demand: the software test plan skeleton (scope, environment, per-test details, schedule) and the 10-element test-case template. Practise writing a complete test case from a requirement, making sure it always includes an expected output and a PASS/FAIL exit criterion — that is the difference between a test case and mere test data. Learn the four test levels and be able to draw the V-model pairing each level with its development stage. Keep the key IEEE 829 contents and the types-of-tests list (functional, integration, UAT, performance) as quick-recall lists for the multiple-choice section. Since the mid-term quiz question is released this week and it is a milestone-check week, keep your project test plan current. Confirm the exam format on Canvas.
Working through The Software Test Plan in ELEC5618? Sia is AskSia’s AI Software Engineering tutor — ask any ELEC5618 The Software Test Plan 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.
