How QA testers can complete the operator practicum

QA testers complete the operator practicum by deciding, for two weeks, a software company's agent output: bug triage calls, duplicate closures, customer ticket replies, release notes and held production actions. Each decision carries a reason. You pass with nineteen in twenty correct and no missed red line, and a Pryme assessor signs off the log.

Is the practicum testing the agent or you?

You. That is the first adjustment for a QA tester. Your instinct is to find every defect in the agent, file it and move on. In the practicum, your job is to make the right call on each item in front of you, with a reason, at a steady pace. Noting the agent's weaknesses is useful, and it may feed changes to its brief or sources, but the score is about your decisions.

The practicum is half of Certified Pryme Operator; the written exam is the other, covered in how QA testers prepare for the operator exam. If your company uses Pryme you work its live queue; otherwise a simulated software support queue in a free workspace.

What will the queue contain?

• Incoming bug reports the agent has triaged by severity and component.
• Reports the agent proposes to close as duplicates or "works as designed".
• Draft replies to customers on support tickets.
• Draft release notes listing fixes and changes.
• Requests to turn a feature flag off, roll back a release, or grant beta access.
• Logs and screenshots attached to tickets, sometimes containing more than they should.

Provenance helps you weigh each one. The build system, the test results and the issue tracker's history are sealed. A report from a named enterprise customer through the support portal is signed. A user's description of a bug is declared. A screenshot or log pasted from outside, or a post on a public forum, is external.

The steps

1. Agent, depth 1: reads the report, logs and history and links duplicates.
2. Agent, depth 2: drafts the triage, closure, reply or release note and holds it, naming the bound that decided.
3. You: try to reproduce, or check the evidence, for anything rated low severity or proposed for closure.
4. You: decide: approve, edit, reject or escalate.
5. You: write the reason, citing the build, test or report.
6. Agent, depth 3: applies approved routine changes within bounds, such as labels and links.
7. Engineering lead: acts on rollbacks, flags and security issues, which are held at depth 4 or routed to a named team.
8. Agent, depth 1: files each verdict in the append-only record for the assessor.

Which red lines will the assessor check?

• Closing or downgrading a report that describes a security vulnerability.
• Approving a reply or public note that exposes customer data, credentials or another customer's details from a log.
• Approving release notes that claim a fix the test results do not show as verified.
• Approving a production action, such as a rollback or flag change, outside your authority.
• Closing a report as a duplicate when the reproduction steps differ in a way that matters.

One miss fails the practicum.

What does a worked decision look like?

An illustrative case. A user reports that exporting a large report "hangs". The agent links it to an existing performance ticket and proposes closing it as a duplicate. The attached log shows an authentication error, not a timeout, and contains a session token. You reject the closure with the reason "log shows auth failure, not the performance issue in the linked ticket; different defect; token in attachment redacted and security team notified". That is three calls in one item, each tied to evidence.

Which controls protect users and you?

• Held production actions. Evidence: the named lead who acted.
• Provenance tags. Evidence: whether a claim came from the build system or a user's description.
• Security routing. Security reports go to a named team, not a general queue. Evidence: the routing entry.
• Append-only record. Evidence: a trail for post-incident reviews.

What should you measure?

Correct decisions over total. Duplicate closures you rejected and why. Severity changes. Sensitive data you caught in attachments. Patterns in the agent's triage errors make good material for a post-practicum note and for interviews.

Time yourself on reproduction attempts. If you spend more than a few minutes reproducing an issue before deciding, ask whether the decision really depends on it. Many triage calls can be made safely on the logs and test results alone, and holding the queue for a full reproduction is its own kind of error.

Where does it usually go wrong for QA testers?

Turning each item into a full investigation. You have a queue to clear and a standard to meet. Reproduce where the decision depends on it; otherwise decide on the evidence.

Testing the agent instead of deciding. Filing ten observations about its phrasing is not a decision. Payroll administrators, with a very different queue, face the same discipline of deciding on evidence in how payroll administrators complete the practicum.

Where the Academy fits

Pryme Intelligence Academy runs the practicum to the same standard on live and simulated queues. QA testers who later want to design and certify agents can move on to the Builder track, which needs Operator first. The AI operator certification guide explains what the Operator certificate proves.