About Us
Queue builds robots to fill prescriptions. Our machine is designed to take stock bottles of medication and produce counted, labeled vials, so that pharmacists and technicians can spend their time on patients. Our first product is built to work behind the pharmacy counter and to be operated by pharmacy staff.
About the Role
You own the evidence that Queue's software, firmware and models do what we say they do. You are answerable for three things: every release to a machine carries a record a customer or an assessor can follow from requirement to test to result; every hazard that software controls traces to a test that proves the control; and every accuracy figure the company states has a written method and raw data behind it. Most of this evidence should come out of automation that you build and that runs without you.
What You'll Own
- Validation — The plan for showing that software, firmware and models meet their requirements on the real machine, and the automated verification that carries it out. You own the checks that run on every change and the checks a release must pass.
- Requirements and hazard traceability for software — The trace from each software requirement, and each hazard that software controls, to a test and a result. You own that trace for software, working with systems engineering, and keep it current as the code changes.
- Release evidence — For each release: what changed, which versions, which tests ran, what they showed, and which exceptions were recorded and by whom. This covers model changes as well as code, including the evaluation record a model needs before it is promoted.
- Accuracy evidence — The written evidence requirement behind any number Queue states about counting or checking: the sample, the method, the pass criteria set before the run, and the raw data kept afterwards. You keep that requirement with the hardware and vision leads, run the measurement with them, and check each figure against it before it is used.
- Acceptance evidence — Where a customer witnesses an acceptance test, you own its evidence pack, produced from the automation: criteria, method, raw results, exceptions and sign-off.
- The environments tests run in — You are the first customer of our test environments and you set what they must provide, with the engineers who build them.
What stays with others, so that you know where your work stops. Systems engineering keeps the machine-level requirements and their traceability, and you work with them where the software trace joins theirs. Hardware engineering keeps hardware verification. You produce the evidence and say plainly what it shows. Technical readiness for a release is decided by software leadership, a release that misses its criteria is held, and you do not accept risk on the company's behalf.
First 90 Days
- Day 30: You have run the test suites and the end-to-end harness yourself and written your own map of what they prove across the cloud service, the on-machine software, firmware and vision. You have sat down with the hardware and vision leads on the evidence requirement for accuracy figures.
- Day 60: You have produced the evidence record for a release, in a format you defined. The check on a model's evaluation record before promotion is yours. You hold the trace from requirement to test for the path that releases a fill to be dispensed.
- Day 90: You have produced an acceptance evidence pack from the automation. You have run a measurement against the evidence requirement for accuracy figures, with the hardware and vision leads. You hold the trace from each hazard that software controls to the test that proves the control.
What We're Looking For
Must-Have
- Ownership — you have owned verification or release evidence for a system where a wrong result had consequences, and you stayed with it through a release that went wrong.
- You build the automation — you are fluent enough in the languages of the systems you verify to write the harnesses yourself. Ours are…