The implementation stage is where the design is turned into actual working code. Programmers use the design documents (pseudocode, structure charts, data flow diagrams) produced in the design stage as a blueprint. Good implementation includes:
Coding standards: consistent naming conventions, indentation, and commenting. Modular programming: writing small, self-contained functions/procedures that each do one thing — making code easier to test, debug, and reuse. Version control: saving incremental versions of code so changes can be tracked and rolled back if needed.
Testing checks that a system works correctly and meets its requirements. Different types of testing happen at different stages of development.
Testing individual functions or modules in isolation. Each unit is tested independently before integration. Identifies bugs at the smallest level. Typically performed by the developer who wrote the code.
Testing how modules work together after unit testing is complete. Checks that interfaces between components function correctly. May reveal new bugs not found in unit tests.
Testing the complete, integrated system as a whole. Checks that all functional and non-functional requirements are met. Includes performance testing, security testing, and usability testing.
Testing performed by the client or end users against the original requirements. Determines whether the system is ready for release. Also called User Acceptance Testing (UAT).
These two approaches differ in whether the tester knows how the code works internally.
Good testing uses a range of carefully chosen test data to check all scenarios. There are three key categories:
Data that should be accepted and processed correctly. Tests the typical use case. Example: entering age as 25 when the valid range is 0–120.
Data that should be rejected. Tests that the system handles incorrect input gracefully. Example: entering "cat" as an age, or a negative value.
Data at the edges of what is valid. Tests the exact limits. Example: entering 0, 1, 119, 120 when the valid range is 0–120. Bugs often occur at boundaries.
A good test plan lists each test, the test data used, the expected outcome, and the actual outcome. If actual ≠ expected, a bug has been found.
| Test No. | Description | Test data | Expected result | Actual result | Pass/Fail |
|---|---|---|---|---|---|
| 1 | Valid age input | 25 | Accepted; proceed to next step | Accepted; proceed | Pass |
| 2 | Boundary — lower limit | 0 | Accepted | Accepted | Pass |
| 3 | Boundary — upper limit | 120 | Accepted | Accepted | Pass |
| 4 | Boundary — just above upper | 121 | Error message displayed | Error message displayed | Pass |
| 5 | Invalid — text input | "hello" | Error: "Please enter a number" | Error message displayed | Pass |
When tests reveal failures, developers must debug the code — find and fix the cause. Modern IDEs (Integrated Development Environments) provide debugging tools including breakpoints (pausing execution at a specific line to inspect variable values), stepping through code line by line, and watch windows that display variable values in real time.
Iterative development means the cycle of code → test → fix → retest is repeated many times throughout development. This is the key characteristic of agile approaches: rather than completing the whole system before testing, developers build small working portions, test them immediately, and use feedback to guide the next iteration.
8 questions · 24 marks
| Term | Definition |
|---|
Timed exam conditions.