My clearest recent lesson about checklists came from preparing the FreshTrack project for assessment.
The difficult part was not only writing code. The submission had to prove that the code, tests, screenshots, object names, documentation, and final evidence all agreed with each other.
Knowing the project was not enough
I could have a working feature and still submit weak evidence.
The test plan broke the project into explicit checks: the interface, CRUD behaviour, JavaScript and DOM work, API evidence, GitHub structure, and later the Java/BlueJ assessment tests.
For the Java part, the documentation was reduced to three focused test cases: base class, inheritance, and polymorphism. Each one needed the correct objects, method calls, expected result, and evidence.
That structure mattered because “I know this is in the project” is not the same as “I can prove this requirement has been satisfied.”
The checklist exposed small inconsistencies
As I worked through the documentation, I kept checking whether the required content and information were actually present.
One review exposed a naming mismatch between the documented object name and the object I had actually created in BlueJ. The documentation referred to one packaged-food object name while the live Object Bench used packaged1.
That is the kind of detail that is easy to overlook when the underlying code is already understood.
I also encountered a problem in the DOCX itself and needed a repaired version before continuing. Again, the issue was not a lack of subject knowledge. It was an execution and evidence problem.
PASS and CONFIRMED were not the same thing
Another useful distinction was keeping executed evidence separate from structure that had only been confirmed in the code.
A test case could be marked PASS when I had actually run it and observed the result. Something could be CONFIRMED when the structure was present but the runtime evidence had not yet been captured.
That prevented the documentation from claiming more than the evidence showed.
The checklist became a reliability tool
The value was not that a checklist made the project intelligent. It made omissions visible.
I could ask, one item at a time:
- Was the test actually executed?
- Does the screenshot show the right object or result?
- Does the name in the document match the live object?
- Is the result observed, or only structurally confirmed?
- Is the evidence inserted into the final document?
- Does the final submission still run and match the repository?
Those are simple questions. That is exactly why they are useful. They protect details that are easy to assume have already been handled.
The limit
A checklist did not replace understanding the project, and it could not tell me whether the underlying design was good. I still needed to understand inheritance, polymorphism, DOM behaviour, API calls, and the rest of the work.
What it changed was the reliability of the handoff. The checklist helped make sure that what I knew, what I tested, and what I submitted were describing the same project.