Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
04-Soft-A6, Software Quality Assurance — National Exams, May 2018 (3 hours, open book, 8 questions of equal value; the first FIVE as they appear in the answer book are marked — all eight are solved here as a study resource).
Part (a) — verification activities across the SDLC. Verification asks "are we building the product right?" — i.e., does each work product correctly implement the specification handed to it, regardless of whether that specification is ultimately what the customer wanted (that question is validation). Verification activities are attached to whichever phase produced the work product being checked: requirements-phase verification uses requirements reviews and walkthroughs to check the SRS is internally consistent and unambiguous; design-phase verification uses design reviews to confirm the design correctly and completely implements every requirement (traceability); coding-phase verification uses code reviews/inspections and static analysis to confirm the code correctly implements the design; and unit/integration testing is itself a verification activity, using white-box techniques to confirm the code's internal logic behaves as the design intended. Each phase therefore gets its own verification technique, chained so that the output of phase N is checked against the (verified) input handed down from phase N−1.
Part (b) — fault prevention vs. fault tolerance vs. fault detection.
Fault prevention stops faults from being introduced in the first place — disciplined requirements/design practices, coding standards, formal methods, and staff training all reduce the rate at which new faults enter the product.
Fault tolerance lets the system keep operating correctly (possibly at reduced capability) even though a fault is present and has been triggered — achieved through redundancy (N-version programming, recovery blocks), exception handling, and checkpoint/restart mechanisms. The fault is not removed; its consequences are contained.
Fault detection discovers that a fault exists (or has just caused a failure) so it can be corrected — through testing, runtime assertions, monitoring and logging. Detection on its own neither prevents the fault from being introduced nor keeps the system running when it fires; it only makes the fault visible.
The three are complementary layers of defence: prevention reduces how many faults exist, tolerance limits the damage from the faults that remain, and detection finds the faults that neither prevention nor tolerance dealt with, so they can be permanently fixed.
Part (c) — system test, functional test, performance test.
System test exercises the fully integrated computer-based system as a whole — hardware, software, people and data together — to confirm all elements have been properly integrated and perform their allocated functions; it is an umbrella category under which several specialized tests (recovery, security, stress, performance) are run.
Functional test (behavioural/black-box testing) exercises the software purely against its stated functional requirements through its external interface, without regard to how the internal code is structured, to confirm the system does what the specification says it should.
Performance test is designed to verify the run-time performance of the software within the context of the integrated system — response time, throughput and resource utilization under realistic and peak load — and is typically run throughout system testing rather than as a single isolated step, often requiring extra instrumentation to capture the timing data.
