Task 6 Testing Log Template
Testing Purpose
Testing should show that your coded product works, handles expected input and responds sensibly when something goes wrong.
Your testing must connect back to your requirements and user needs.
1. Test Plan
| Test number | Requirement or feature tested | Test data | Expected result | Actual result | Pass/fail | Fix needed |
|---|---|---|---|---|---|---|
| 1 | Normal data | |||||
| 2 | Boundary data | |||||
| 3 | Invalid data | |||||
| 4 | Selection logic | |||||
| 5 | Loop logic | |||||
| 6 | User flow or interface | |||||
| 7 | Final result or summary |
2. Required Test Types
| Test type | What it means | My example |
|---|---|---|
| Normal data | input the user is expected to enter | |
| Boundary data | input at the edge of an allowed range | |
| Invalid data | input the program should reject or handle | |
| Logic test | checks a decision, loop or calculation | |
| User test | checks whether a user can follow the product |
3. Debugging Notes
Record errors you found and how you fixed them.
| Error type | What happened | Evidence | How I fixed or managed it |
|---|---|---|---|
| Syntax error | |||
| Run-time error | |||
| Logical error | |||
| Usability issue |
4. Trace Table Evidence
Paste or attach the trace table from your algorithm design. Explain what it proved.
5. Validation Evidence
Ask a user or classmate to try your product.
| Question | Notes |
|---|---|
| What did the user try to do? | |
| What worked clearly? | |
| What confused them? | |
| What change did you make or consider? |
6. Evidence to Include
Include screenshots, copied output, screen recording stills or teacher-approved evidence showing:
- the program running successfully
- normal data test
- boundary data test
- invalid data test
- at least one issue you found or fixed
- final output or summary screen
- any validation feedback used for iteration