Skip to content

What it does today

The honest list. It is here so that you can tell before you start whether XPressRT covers what you need, rather than finding out halfway through a procedure.

What works

  • Procedures, test cases and steps, with variants, shared preparation, and preparation and clean-up around procedures and test cases.
  • Steps that need no equipment: ask the operator, read data points, set data points, record a serial number, wait.
  • Data points with unit, direction and range; the criterion on the step — limits, reference and tolerance, repeats, and the mean of a series.
  • The operator's side: dialogs naming the procedure, test case and step, a message field on every one of them, defect and proof reports, cancelling a step, stopping a run.
  • The record: a report per procedure with everything hanging at its step, a run summary, defect and proof pages, readings with their limits, charts, and machine-readable output beside them.
  • Runs: every run listed with its outcome, its steps and its downloads.
  • Suites and plans, with cycles, progress, coverage and a plan report.
  • Workspaces in a folder of your own or inside the browser, as plain files you own.
  • Blocks: step bodies written as blocks, read as sentences, approved as a state, extended by the workspace's own blocks — and run in the browser.
  • Python steps: a step whose body is your own code, run on your machine by the local step runner, with breakpoints in your editor. Needs the workspace in a folder and Python 3.9 or newer.
  • Courses over time: stamped values per data point, collecting, waiting for a limit, timing between events — measured from a mark a step sets (MARK, since = AT(…)), with the stamp and clock of whoever knew the moment.
  • Runs step by step, and dry runs.
  • An AI assistant connected over MCP, working through the open window — several at once, with the workspace folder as the only thing to configure. It can start a dry run; what it changes carries the tag ai-generated.
  • What an agent works out, kept as a state you decide about: Onboarding (tests you already have, brought in, with where each came from), Coverage (what the requirements ask and what the test cases check, with the findings and your decisions), and Intelligent Regression (what a change affects in your test cases, with the evidence, and what you decide about it). Every run is checked before it is accepted, and what you decide is kept beside it under your name.
  • Tags on test cases, procedures, steps and plans, with colours.

All of it in the browser: no installation, no account, nothing uploaded — with one exception you choose yourself: the code of a Python step you wrote by hand runs on your machine.

Announced, not there yet

  • Blind spots. The page is in the application and says what it will do: hold code, requirement and test case against each other and name where they disagree — above all the test that was written from the code rather than from the requirement, which looks green and proves nothing. Nothing runs there yet; it carries no numbers, because an invented figure on a preview page reads like a result.

What is not there

  • Instruments. A reading is asked of the operator. The part that binds a data point to real hardware is designed, not built, and the step types that once addressed an instrument directly — measure, power supply, switch, communicate, program — have been taken out: nothing served them, and they stood in the picker greyed out, explaining nothing. What comes back will come back through the data point, so the step that names it stays as it is.
  • Calibration. Neither the measuring instrument nor its calibration state is part of the record.
  • Sign-off. A block step is approved by a named person, but there is no signature and no identity behind it, and nothing approves a release.
  • Roles and accounts. No login and no permissions: everyone at the machine can do everything.
  • Requirements management. XPressRT does not replace Polarion, Codebeamer, Jama or DOORS, and writes nothing back to them. It has no connector of its own either: what comes in comes through your assistant, which reads the source and hands in what it read — and every run names the source and the version it counted with. Traceability is what you get from tags on test cases, from the coverage of a plan, and from the coverage state.
  • Document import by the application. XPressRT reads no test instruction itself. An assistant can read one and write the test cases from it — that is Onboarding, and every test case carries the line saying where it came from — but there is no import button, and nothing is parsed unattended.

Known limits

  • Opening a folder needs Chrome or Edge. Other browsers offer the workspace inside the browser only.
  • A run lives in the page. Navigating away ends it, and what it got through is written as a report. Reloading or closing the tab ends it without one: the report is written at the end of the run, and a reload takes the page — and with it the run — away before that.
  • Data points are numeric, or a named list of values. Other kinds are not implemented.
  • An assistant is not told when a person cancels its dry run. It finds out the next time it asks what the run is waiting for.
  • A stopped run needs a few seconds. It skips the rest, cleans up and writes its report. A run that is deep in a calculation and never asks anything again cannot be interrupted; after half a minute the runtime is restarted and that run leaves no report.
  • Agent pages read what an agent hands in. XPressRT checks a run before it accepts it — every claim needs its evidence — but it does not recompute the analysis. What is judged is judged by the agent, and what is decided is decided by you.