By Lunibyte Team · November 1, 2026 · 4 min read · Guide

A minute-based classical test scheduler for dependencies, shared resources and working shifts.

LuniTestPlan Guide: Build, Replan and Save a Test Campaign

Use this walkthrough to create a small fictional test campaign in LuniTestPlan. You will define a working calendar, reserve equipment, add dependencies, test a scheduling change and leave with a reusable plan file. The tool runs a classical scheduling heuristic; it does not execute tests or operate equipment.

Before you start

Use made-up IDs and a small example you can verify manually. Keep a separate original of any plan you import. The workspace is memory-only: loading the page does not create a cloud project or an automatic backup. Static site requests reach hosting, but your plan file is read locally.

The synthetic sample contains Power-on, Functional and Thermal tests. Loading it replaces the current inputs. If there are unsaved edits, the application asks before replacing them; cancel if you need to download your existing plan first.

Step 1: Set the working calendar

Choose the start date, planning days, shift start and shift end. Select the weekdays on which work can occur. A simple practice setup is Monday through Friday, 08:00–17:00, for five calendar days. The planning-days field describes the calendar window, not a count of working shifts.

All times belong to one shared wall-clock calendar. The tool does not convert between sites or timezones. Shift end must be after shift start, and every test must fit within one uninterrupted shift. An overnight test or a test paused across multiple days needs a different model rather than a misleading duration.

Step 2: Add resources and tests

Create named resources such as Bench A, Device and Engineer. Set each resource's parallel capacity. In the test editor, give every activity a unique ID and a duration in whole minutes. Select its resources and dependencies. Multi-select controls support the platform's normal selection gestures; on a desktop, Ctrl/Command or Shift can select several entries.

Let Power-on require Bench A and Device. Let Functional depend on Power-on. A dependency references the test ID, not a descriptive sentence. Renaming an existing ID updates its references; removing a referenced item requires repairing the remaining references before calculation. Circular dependencies are rejected.

Use Find a test to narrow a long list by test ID, resource or dependency. Collapse all tests to scan their summaries, then expand the entries you need to edit. These controls change what is visible, not what participates in scheduling.

Step 3: Enter priorities and timing constraints

Priority 9 is the highest. A not-before date/time prevents early scheduling and is useful when a test article or operator will arrive late. A finish deadline is a hard limit: the test must finish by that time for a feasible result.

A locked start reserves a fixed interval before flexible work is placed. Use a lock only for a slot you intend to preserve. It is a planning reservation, not proof that a test has run or passed. Locks can conflict with shift hours, a blackout, a deadline or predecessor completion; those conflicts need a real input change.

Step 4: Mark equipment unavailable

Add a blackout interval with the resource, unavailable-from time, available-again time and number of unavailable units. Intervals are half-open: the resource becomes available again at the entered end time. Overlapping blackouts cannot reserve more units than the resource owns.

For practice, make Bench A unavailable from 10:00 to 11:00. A test that needs that bench throughout its duration must fit around the entire outage. Do not subtract that hour from the duration to conceal the conflict.

Step 5: Calculate and inspect

Press Calculate / replan, or Ctrl/Command+Enter. Check the dated start/end table, resource assignments and finish deadlines. Use the scheduled-window timeline view to enlarge short tests, or switch to the full campaign view for the wider context. Gold bars identify locked tests.

If the tool reports no schedule found, inspect the named test and the constraints in its message. Try a longer window, an adjusted priority or an available resource. Failure is not a mathematical proof of infeasibility. The scheduler is a bounded heuristic rather than an exact makespan optimizer.

Step 6: Replan, then save the right artifacts

After a successful result, delay one flexible test using Not before and calculate again. The comparison lists changed start times for unchanged IDs from the previous successful schedule in this tab. Renamed or removed activities are not a complete historical audit.

Save plan file downloads reusable JSON inputs; Ctrl/Command+S triggers that explicit download. Export schedule CSV produces a dated report, and Print / save PDF uses the browser's print dialog. Reopen the JSON file and calculate to check it, rather than assuming an old output remains valid.

CSV/Excel import can replace the test list after validation, using existing resource IDs and the documented headers. Download the template first, retain its columns, separate multiple resource/dependency IDs with a vertical bar, and use YYYY-MM-DDTHH:MM for optional dates. A downloaded schedule report is not the same schema as the input template. For the reasoning behind this workflow, read the LuniTestPlan overview.