INFOSYS 220 Chap.9 Construction and Testing
Construction and Testing
Build from controlled design evidence
Construction turns approved requirements and design decisions into working components. The work remains analytical because developers must interpret interfaces, data rules, exceptions and dependencies without silently changing scope. Configuration, version control, code review and build automation help keep changes visible and reproducible.
A requirement that cannot be traced into construction is at risk of omission; a component without a requirement may represent unsupported scope.
Use tests to produce decision evidence
Testing compares observed behaviour with expected outcomes.
Unit tests isolate components, integration tests examine interfaces, system tests assess the assembled solution and acceptance tests evaluate agreed user or business outcomes. A useful case states setup, input or action, expected result and evidence. Boundary and failure conditions matter because a happy path alone cannot establish reliability.
Defects should trace to affected requirements, design and regression tests so a correction does not break behaviour that already worked.
What this chapter covers
- 01
Controlled construction from requirements and design
- 02
Versioning, review, configuration and reproducible builds
- 03
Unit, integration, system and acceptance test purposes
- 04
Test conditions, setup, action and expected result
- 05
Boundary, negative and exception tests
- 06
Defect triage, regression and requirement traceability
Worked example · free
Design a traceable access test
- 2Write the authorised success case.
- 2Write an unauthorised denial case.
- 2Add regression scope and evidence.
- 2Classify relevant levels.
Key terms
- Unit Test
- A test of an isolated component or small behaviour under controlled conditions.
- Integration Test
- A test of interactions and data exchange among components or external services.
- System Test
- A test of the assembled solution against system requirements in a representative environment.
- Acceptance Test
- Evidence that agreed stakeholder or business outcomes are satisfied by the delivered solution.
- Regression Test
- A repeated test checking that a change has not damaged behaviour that previously worked.
- Defect
- A discrepancy between observed behaviour and the specified or expected result.
- Test Oracle
- The rule or source used to decide what result should be expected.
Construction and Testing FAQ
Does passing unit testing mean the system works?
No. Unit tests can show that isolated logic behaves as expected, but interfaces, configuration, infrastructure and complete user journeys can still fail. Integration, system and acceptance evidence answer different questions and remain necessary according to the risk.
What makes a test case reproducible?
It states the starting state, data, role, action, expected result and evidence clearly enough for another tester to repeat it. Environment and version should also be recorded when they affect behaviour. A vague instruction to check that it works cannot support diagnosis.
Why test boundaries and failures?
Defects often appear where values are empty, at a limit or just beyond it, and where dependencies are unavailable. Failure tests also examine whether the system protects data, preserves work and gives recoverable feedback rather than merely whether the happy path succeeds.
How should a defect be prioritised?
Consider effect on value, safety, security, data integrity, frequency, affected users, workaround and release dependency. Severity and urgency are related but distinct. Record evidence and rationale so a visible cosmetic issue does not automatically displace a less visible but material integrity failure.
Exam move
Create a small trace matrix with requirement, design element, component, test and result columns. Populate it using one functional requirement and one quality or security constraint. Write a happy path, boundary case, invalid input, dependency failure and recovery case for each. Make every test specify setup, action, expected result and observable evidence.
Classify the tests by level, then explain what each level can and cannot prove. Introduce a defect and write a report containing version, environment, reproducible steps, expected result, actual result and impact. Propose a correction, identify regression scope and show which trace links justify it.
For construction reasoning, review a hypothetical change and decide whether it belongs in configuration, code, data migration or a requirement revision. Do not let implementation convenience silently change the approved behaviour. Practise explaining why a large number of tests is not the same as useful coverage: coverage must follow risk, requirements and meaningful conditions.
Finish by conducting an acceptance walkthrough from the stakeholder goal backward to the test oracle. If expected results rely on personal opinion rather than an approved requirement or rule, strengthen the evidence source before claiming the solution passes.
Working through Construction and Testing in INFOSYS 220? Sia is AskSia’s AI Information Technology tutor — ask any INFOSYS 220 Construction and Testing question and get a clear, step-by-step explanation grounded in how INFOSYS 220 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.