Testing Strategy and Test Case Design
A system is not ready just because it is coded. It must be tested against requirements.
Testing aims to answer: Does the system do what it should do? Does it handle wrong input properly? Does it behave correctly under expected conditions? Does it protect data and maintain integrity?
Common testing levels include:
| Testing level | Focus |
|---|---|
| Unit testing | individual functions or components |
| Integration testing | modules working together |
| System testing | full system behavior |
| User acceptance testing | whether users accept the solution for real use |
What makes a good test case
A test case usually includes: test case ID, requirement reference, purpose, input data, steps, expected result, actual result, pass/fail status.
Example:
| Item | Example |
|---|---|
| Test ID | TC-APPT-01 |
| Requirement | appointment booking |
| Input | valid student ID and available date |
| Expected result | appointment saved and confirmation shown |
Strong test cases cover valid inputs, invalid inputs, boundary values, exceptions, and role restrictions. If your requirement is not clear, your testing will also be weak — that is why testing is closely tied to analysis quality.
Implementation and Conversion Strategies
Implementation is the stage where the proposed system is introduced into actual use. This often includes installation/deployment, configuration, data migration, user account setup, training, pilot run, and official go-live.
A major implementation concern is the conversion strategy — how the old system is replaced.
| Strategy | Meaning | Main advantage | Main risk |
|---|---|---|---|
| Direct cutover | old system stops, new system starts immediately | fast | risky if failure occurs |
| Parallel run | old and new systems run together | safer verification | more work and cost |
| Pilot | new system starts in one unit first | limited risk | slower full rollout |
| Phased | modules are introduced gradually | manageable transition | coordination complexity |
The best conversion method depends on system criticality, user readiness, cost tolerance, available time, and rollback needs. For example:
- Payroll systems often prefer parallel or pilot due to risk.
- A low-risk internal tracking tool may use direct cutover.
- Complex institutional systems often benefit from phased implementation.
Documentation, Training, Support, and Maintenance
ProReviewer — locked
Drills, code labs, and full solutions.
Practice & Exam Drills — Lesson 7
ProReviewer — locked
Drills, code labs, and full solutions.