A software course audit checklist for educators
A software course audit is narrower than a course review. This checklist covers one thing: whether the technical claims in your lessons still hold, and what to do about each one that does not.
TeachCurrent editorial team · Published · 7 min read
Inventory
Start with a list of every lesson, not every claim. Mark each lesson as source-dependent (it tells students to do something in software) or conceptual (it explains why). Only source-dependent lessons enter the checklist. On a typical software course that is 40–60% of the material, and skipping the rest is the single biggest time saving available.
Intended version
Write the intended version at the top of the audit, not per row. Every judgement below depends on it. Without it you will drift into rewriting a version-X course as a version-Y course halfway through, which is a different project.
The checklist columns
Copy this structure into a spreadsheet, one row per checked claim.
| Column | What goes in it |
|---|---|
| Course | Which course and module the row belongs to. |
| Intended version | The release the lesson was recorded against. |
| Lesson | Lesson title or number. |
| Timestamp | Where the claim appears, if the transcript is timed. |
| Claim | The specific instruction or statement being checked. |
| Evidence URL | The documentation page that confirms or contradicts it. |
| Evidence date | The date you read that page. |
| Confidence | Confirmed, likely, or unverified. |
| Priority | Blocking, misleading, or cosmetic. |
| Action | Update, keep with note, or retire. |
| Completion note | What you did, and why — dated. |
Evidence and confidence
A row without an evidence URL and date is not finished. Confidence is about how the evidence was obtained, not how sure you feel:
- Confirmed — you reproduced the behaviour, or official documentation states it plainly.
- Likely — documentation implies it but you did not reproduce it.
- Unverified — a forum post, an AI summary, or a memory. Unverified rows never justify an edit on their own.
Lesson and timestamp
Point at the passage, not the lesson. “Lesson 12 is outdated” costs you a full re-watch later; “Lesson 12 at 04:18 names a panel that has moved” is a ten-minute fix. If your transcripts are untimed text, quote the first eight words of the passage instead.
Priority
Sort by learner impact before effort. Blocking rows first — a step that cannot be completed stalls everything after it. Misleading rows next. Cosmetic rows are batched, and some are never worth fixing.
Action and verification
Every row closes with one of three decisions:
- Update — edit the lesson, add a dated note, or re-record the affected segment. Re-check the row afterwards and record who verified it.
- Keep — the lesson is correct for the version it teaches. Record why, so the next audit does not reopen it.
- Retire — the lesson teaches an approach that is now wrong and not worth salvaging. Remove or replace it, and check which later lessons depended on it.
Closing the audit
An audit is done when every source-dependent lesson has either been checked or explicitly deferred with a date. Half-finished audits are worse than none, because they get remembered as clean bills of health. Write the finish state down: lessons checked, rows open, next review date.