A minute-based classical test scheduler for dependencies, shared resources and working shifts.
In this article
LuniTestPlan: A Practical Schedule for Tests, Benches and Working Shifts
A test list is not yet a test schedule. Three tests can each look reasonable on paper and still be impossible to run together because they require the same bench, the same device, or a predecessor that has not finished. LuniTestPlan makes those conflicts visible in a small, browser-local planning workspace. It is an ordinary engineering tool in Tool Hub, not a quantum algorithm.
What the planner actually does
LuniTestPlan accepts named tests, durations in whole minutes, shared resources and finish-to-start dependencies. A resource can represent a bench, an instrument pool, an operator or a facility. Every test reserves one unit of each resource selected for its full duration. Giving a device pool a capacity of two permits two simultaneous reservations; it does not let a single test demand an arbitrary number of devices.
The working calendar defines a start date, a planning window, working weekdays and a daytime shift. The scheduler finds intervals that fit entirely inside a shift and respect resource capacity. A test is not split around lunch, an overnight boundary or an equipment outage. Its duration therefore needs to describe an uninterrupted reservation, including whatever setup and cleanup you decide to include.
When a bench outage changes the answer
Imagine a fictional campaign with Power-on, Functional and Thermal activities. Functional and Thermal both wait for Power-on, but they do not necessarily need the same equipment. With sufficient device capacity, they may overlap. If the shared bench is unavailable from 10:00 to 11:00, a two-hour test cannot simply begin at 09:00 and ignore the outage. It needs a later continuous slot.
This is why resource availability and dependencies are separate inputs. A dependency says which work must finish first. A blackout says when a resource cannot be reserved. A not-before time models a delayed release. A locked start holds an agreed slot fixed while the remaining work is recalculated. Combining them is more useful than drawing bars first and hoping the constraints work out later.
How the schedule is chosen
The tool uses a deterministic classical heuristic. Among dependency-ready tests, it considers higher priority first, then earlier finish deadlines, then input order. It searches for the earliest working interval with capacity. Locked tests are reserved before flexible work, so recalculation does not quietly move a fixed commitment.
A successful result is a feasible schedule under those entered assumptions. It is not a proof that the schedule is shortest or globally best. If no slot is found, the message is deliberately more limited than “impossible”: another priority order, a different lock or a larger horizon could produce a schedule. Hard finish deadlines can also prevent a result even when a later schedule would otherwise fit.
Where the useful record lives
The dated table and zoomable timeline describe the same calculated schedule. The workload summary shows resource-minutes used against the entered working capacity after blackouts. Waiting explanations identify constraints encountered during the search; they are not a certified root-cause analysis or a project-wide critical path.
Save the input plan as JSON if you want to reopen it. Export the schedule as CSV for inspection or handoff, or use the print/PDF action. These are different artifacts: a schedule CSV is a report, while the saved plan file retains the inputs needed to recalculate. Editing an input invalidates the previous export until you calculate again.
Why keep it local and bounded?
A lightweight local planner can be useful for quick what-if work without creating a shared project account. The application keeps inputs in page memory and reads imported files on the device. Static page requests still reach the host. Closing or reloading an unsaved workspace loses its contents; explicit file saving is part of the workflow.
The present limits matter: up to 100 tests, 30 resources, 200 blackout intervals and a 30-day window, with one nonpreemptive daytime shift per working day. Dates are shared wall-clock planning times, without timezone or daylight-saving conversion. There are no instrument-control commands, automatic execution records or organization-specific approvals.
Start with the synthetic example and compare its result with a small schedule you can check by hand. Then try an equipment outage or a delayed predecessor. The value is a clearer engineering decision, not a quantum label or an unsupported claim to outperform established scheduling systems. Continue with the step-by-step guide.