The Queue That Never Drains
A shared services team is delivering a new invoice-processing solution. During UAT, testers load 5,000 items into a work queue. The process works items in a single priority band, oldest first. About 8% of items fail with a business exception (missing PO number) and are marked as an exception but left in the queue in 'Exception' status. The team's dashboard counts all items in the queue, including exceptions, as 'pending'. Stakeholders see 400 items perpetually pending and believe the process is broken. Separately, the team plans to go live with no volume testing beyond the 5,000-item UAT run, and the production forecast is 30,000 items per month with a 12-hour nightly window.
1. Explain the dashboard confusion and recommend how exception items and queue metrics should be handled in the design and reporting.
Read the worked answer
The dashboard conflates two different states. Items in 'Exception' status are not pending work for the bot; they are waiting for a human. Counting them as pending makes the queue look permanently backlogged and erodes trust in the solution.
Design fix: business exceptions should be routed to a separate exception queue, or at minimum tagged with a distinct status and a reason code. The human review team works that queue; the bot's queue shows only items it can act on. This also gives the review team a clean worklist and a measurable SLA.
Reporting fix: the dashboard should show four numbers separately - new, in progress, completed, and exception. Pending should mean 'available to the bot'. Add an ageing view for exceptions so unresolved items surface.
Process fix: missing PO numbers are a data-quality issue upstream. Track the exception reason distribution; if 8% of invoices lack a PO, that is a supplier or intake problem worth fixing at source, not just a queue to clear. The exam judgement is that exception handling is a design decision with reporting consequences, not an afterthought.
2. Assess the readiness for go-live given the forecast of 30,000 items per month and a 12-hour nightly window, and state what testing is required.
Read the worked answer
The UAT run of 5,000 items does not validate the production profile. Thirty thousand items per month is roughly 1,000 per night on average, but volume is rarely uniform: month-end and quarter-end concentrate it. A realistic peak might be three to five times the average, so the design must be tested at peak, not average.
Required testing: a volume test at peak load (for example 5,000 items in one night) measuring throughput per item and total runtime against the 12-hour window with headroom. A soak test over several consecutive nights to catch memory growth and session degradation. A failure-injection test to confirm retry and exception routing behave under load. And a test with the human review queue active, since 8% exceptions at 30,000 items is 2,400 items per month for reviewers.
If the volume test shows the window is at risk, options are parallel runtime resources, splitting the queue by priority so critical invoices run first, or reducing per-item time. Going live without peak volume testing risks a month-end failure that the UAT run would never reveal.