Testing LMS Completion Reports in Iraqi Organizations

Imagine the quarterly training report from an oil services company’s LMS software showing 96% completion for the mandatory safety induction. Then the HSE manager in Basra checks a sample against site records. Two employees marked ‘completed’ never passed the assessment. One who failed twice and passed on the third attempt appears as ‘failed’. Eleven who attended the classroom version at a field site are missing altogether.

None of this means the LMS software is broken. Each number followed a rule; the problem is that nobody in HR, HSE or audit had checked what the rule was. A completion report is only as reliable as its definition of ‘completed’, ‘failed’ and every status in between.

This article is for HR, IT and procurement teams in Iraqi organizations, whether they support a ministry training unit, a bank, a telecom operator or an industrial company. It sets out test cases for completion, failure, and retry, explains how to read the status definitions behind the report, and shows how to check that the report, the learner record, and the export agree before any LMS software report goes to management.

Why ‘Completed’ Can Mean Different Things in LMS Software

Learning technology standards treat completion and success as separate facts, and that distinction is the first thing to check in any LMS software. In the xAPI specification published by ADL, a result can record ‘completion’, which indicates whether the activity was completed, and ‘success’, which indicates whether the attempt was successful, as two separate properties. An employee can finish every screen and still fail, or pass a test without opening all the content.

The cmi5 specification makes the rule explicit. Each course unit has a ‘moveOn’ setting that tells the LMS when the unit counts as satisfied: when it receives a ‘Passed’ statement, a ‘Completed’ statement, both, either one, or with no condition at all. Two courses in the same LMS software can therefore count as complete under different rules, and one ‘completed’ column can hide that difference.

Whether or not your LMS software uses these standards, the question is the same: for each course, what event turns an employee into ‘complete’ in the report, and who decided?

Write Down What Each LMS Software Status Means

Ask the LMS software provider or your administrator to give you, in writing, the definition of every status your completion report can show. A one-page table is enough. For each status, record:

• The event that sets it: opening the course, viewing all content, reaching the pass mark, or an administrator’s action.

• Which date the report shows: first completion, latest attempt, or the date a record was edited.

• Which score the report shows after several attempts: first, highest, or most recent.

• Whether an exemption counts as complete, and whether the reason and the approver are visible.

• What happens to the status when the course is assigned again for an annual refresher

Exemptions deserve care. cmi5 defines a ‘Waived’ statement for when a unit’s requirements are met by means other than its normal criteria, and requires it to include a reason. Whatever your LMS software calls this status, an auditor will expect the report to show why the requirement was waived and who approved it.

Then agree on the statuses HR and management will actually use. Six labels in Arabic and English, each with a one-line definition, are easier to report on than whatever the LMS software shows by default.

Test Cases to Run in Your LMS Software

Set up a test course with an assessment and a pass mark, and a handful of test accounts in your LMS software. Before running each case, write down the result you expect to see in the report. Then compare.

Completion Cases

• Content viewed, no assessment: in a course where viewing is enough, expect ‘completed’.

• Content viewed, assessment failed: in a course that requires a pass, expect ‘failed’ or ‘in progress’, never ‘completed’.

• Assessment passed without viewing all content: check whether your rule requires both.

• Classroom session recorded in the LMS software by an administrator: expect ‘completed’, with the source, the trainer and the date of entry visible.

• Course updated after completion: publish a new version and expect the report to show which version each employee completed, and whether earlier completers must take the new one.

Failure and Retry Cases

• Failed once, passed on retry: expect ‘passed’, with both attempts in the history and a clear rule on which score and date appear.

• Failed up to the attempt limit: expect a status showing that the employee is blocked, and check who is notified.

• Session interrupted during the assessment: check whether it counts as an attempt; cmi5, for example, records an ‘Abandoned’ statement when a session ends abnormally.

• Passed last year, assigned again this year: expect a new record for the new cycle, with last year’s result kept in the history. cmi5 creates a new registration for re-taking or recurrent courses.

The interrupted session matters wherever connectivity or power is unreliable at some sites. If your LMS software quietly counts a dropped connection as an attempt, employees at field locations may be marked as failed for reasons that have nothing to do with their knowledge.

Run every case twice: once on a computer at head office and once on a phone using mobile data, as employees at branches and field sites will use the LMS software.

Check That the Report, the Learner Record and the Export Agree

For each test account, compare three views: the employee’s own record in the LMS software, the completion report a manager or administrator sees, and the exported file HR will send onward. All three should show the same status, date, score, and attempt count. If they disagree, the LMS software report is using a different rule from the record, and that difference will eventually reach an audit.

Then check the totals. A completion rate depends on who is counted: all assigned employees, active employees only, or everyone except those exempted. Ask how the LMS software treats leavers, new joiners whose deadline has not arrived, and employees on long leave, and make sure the percentage at the top matches the list underneath. Filters need the same scrutiny: a report for ‘the third quarter’ may select employees by assignment date, by completion date or by the date a record was last changed, and each choice produces a different list. Check, too, that Arabic names and dates appear correctly in the export; for the fields it should contain, see our guide to essential fields in LMS report exports.

A Hypothetical Example: An Oil Services Company in Basra

The following example is hypothetical and is included only to show how the tests work.

An oil services company with a head office in Basra and crews at several field sites uses LMS software for its mandatory safety induction, which has a pass mark of 80% and three attempts. Before the annual audit, the training coordinator sets up five test accounts and runs eight cases while the HSE supervisor watches.

Three cases do not match the expected result. A test employee who viewed all content but failed the assessment shows as ‘completed ’ because the course in the LMS software had been set to count viewing alone. A retake after an interrupted session shows two attempts used instead of one. And a classroom session entered by an administrator appears in the employee’s record but not in the export.

The coordinator does not correct the numbers by hand. She asks the provider to fix the course rule and explain the attempt count, documents the export issue with screenshots, and adds a one-page definitions table to the report pack. The next quarterly report from the LMS software shows a lower completion rate, and the HSE manager trusts it more.

Keeping LMS Software Report Definitions Stable

Status definitions in LMS software drift over time. A new administrator changes a pass mark, an update alters how attempts are counted, or a new course is set up with a different completion rule. Keep the definitions table with the report, rerun the core test cases after every major update and whenever a new mandatory course is launched, and record who approved each rule.

Completion reports are one part of the wider tracking and access requirements you set for LMS software, especially in regulated sectors; our article on tracking and access requirements for an Arabic LMS in Iraqi banks covers that list. If your training still lives in scattered files and manuals, build assessable tasks first, as discussed in turning scattered files into assessable eLearning in Iraqi companies.

Summary

A completion report from LMS software is only as trustworthy as its definitions. Completion and success are different facts; retries and interrupted sessions follow rules someone chose, and exemptions need a reason and an approver.

Write the definitions down, run completion, failure, and retry cases with test accounts, check that the report, the learner record, and the export agree, and rerun the tests after every major change. Iraqi organizations that do this can stand behind every LMS software report when management or auditors ask what ‘completed’ really means.

Click here if you want Skillup MENA to help you.