Quality Assurance Engineer

**QA Engineer**

Quality Engineering · Testing a Platform Whose Output Is Generated

• **Function:**

Quality Engineering

• **Reports to:**

Engineering leadership

• **Location:**

Las Vegas, NV — on\-site. This is not a remote or hybrid role.

• **Level:**

QA Engineer

• **Employment type:**

Full\-time

• **Experience:**

Approximately 2–5 years in a software quality role

• **Work authorization:**

Must be authorized to work in the United States

**About the Role**

Regara is a clinical and regulatory intelligence platform for the life sciences industry. Device, pharma, and biotech companies use us to plan and prepare what they need to bring a product to market — regulatory strategy, clinical protocols, study reports, and submission dossiers — across multiple markets.

AI is the product. We run a platform of autonomous agents that research live data, reason over it, and draft complete technical documents end to end. That makes quality a genuinely hard problem.

The output is generated rather than fixed, the same input can produce different text twice, and the artifact at the end is a document a customer files with a regulator.

**What makes this different from most QA work. **

A defect here is not a misaligned button. It is a wrong number, an unsupported claim, or a citation whose source does not say what it is cited for. A generated document can be fluent, well formatted, and wrong — and nothing on the screen will tell you.

Catching those before a customer does is the job.

This is a dedicated quality role. You are not being hired to write product features between test cycles; you are being hired because the hardest quality problem at this company needs someone whose full attention is on it. You will own a test surface end to end — from exploratory passes and the cases you write, through the defect trail, to confirming the fix in production.

**What You Will Actually Work On**

**1\. Exploratory and Functional Testing**

Use the product the way a customer would, then go looking for the places it gives way.

• Run functional and UI/UX passes across dispatch flows, result views, and admin tooling.
• Probe the edges — empty states, oversized inputs, interrupted runs, permissions, and browser and viewport differences.
• Test the workflows customers actually run, not just the screens in isolation.
• Re\-test each release and catch what regressed.

**2\. Test Design and Regression Coverage**

Turn what you learn into something repeatable that outlives any one release.

• Write and maintain test cases and checklists covering core user workflows.
• Own the regression suite the team runs before a release, and keep it current as the product changes.
• Map coverage against the product surface and say plainly where the gaps are.
• Prioritize by risk, not by what is easy to test. A thorough suite over the low\-stakes surface and nothing over the high\-stakes one is worse than no suite, because it looks like coverage.

**3\. Verifying Generated Output**

The most interesting half of this job, and the part with no established playbook.

• Check generated deliverables for internal consistency — numbers, cross\-references, section completeness, and formatting.
• Resolve identifiers and references an agent produces back against the source of record.
• Flag unsupported claims, mismatched attributions, and citations whose content does not support the statement citing them. Citation integrity is the highest\-stakes quality attribute this product has.
• Grade output against golden examples and feed the results back into the eval suite.
• Design test approaches that work when the output is nondeterministic — where "did it produce the expected string" is the wrong question.

**4\. Defect Reporting and Triage**

A bug report is a deliverable. Write it so someone can act on it without asking you a follow\-up question.

• Isolate a minimal, reliable reproduction — not "it sometimes breaks."
• Report with repro steps, expected versus actual, environment, and a severity you can defend.
• Trace a defect back to the requirement or workflow it breaks.
• Distinguish a code bug from a model\-quality issue. They go to different people and get fixed differently, and misrouting one wastes everybody’s week.
• Follow each one through to verification of the fix.

**5\. Release Verification and Quality Signal**

Someone has to be able to say whether a release is safe, and be right.

• Run release verification and give a clear, evidence\-backed read on whether a build is ready.
• Track quality signal over time — defect trends, escape rate, and where in the product problems keep originating.
• Report quality status to engineering in writing, including the parts nobody wants to hear.
• Raise the alarm early when a release is trending badly. A late warning is barely better than none.

**6\. Test Automation**

Move the checks you run by hand into checks that run themselves — where the payback is real.

• Extend backend coverage in pytest and frontend coverage in Vitest and React Testing Library.
• Write browser\-level end\-to\-end checks for the highest\-traffic workflows.
• Keep suites wired into GitHub Actions so failures surface on the pull request rather than after merge.
• Automate judiciously. A brittle suite nobody trusts costs more than the manual pass it replaced.

**Our Stack**

• **Backend:**

Python 3\. 12, FastAPI, SQLAlchemy 2\. 0, Pydantic v2, Postgres / SQLite, pytest

• **Frontend:**

React 19, TypeScript (strict), Vite, TanStack Router \+ Query, Tailwind, shadcn/ui, Vitest \+ RTL

• **AI:**

Frontier LLM APIs (Claude), MCP tool servers, RAG, eval harnesses and golden\-output graders

• **Infra:**

AWS (ECS/EC2, ECR, SQS, S3\), Docker, GitHub Actions

You are not expected to know all of it. Most of your testing runs against the application rather than the codebase — but this is what you will be reading when you chase a bug to its source, and what you will be writing when you extend the automated suites.

**What We’re Looking For**

**Required**

• Roughly 2–5 years in a QA, software quality, or test engineering role, testing a real product with real users.
• Degree in Computer Science, Computer Engineering, or a related field — or equivalent practical experience.
• Comfortable reading and writing code in at least one language. Python or TypeScript put you closest to our stack, but Java, C\+\+, or anything else is fine.
• Attention to detail that catches the value which is subtly wrong, not just the page that will not load.
• Clear technical writing. We will read your bug reports more than your code.
• Able to read a primary source — a spec, a standard, an API contract — and check an implementation against exactly what it says.
• Methodical under ambiguity. You narrow a vague complaint into a minimal reproduction instead of escalating it as\-is.
• Hands\-on experience with at least one testing framework — pytest, Vitest, Playwright, Selenium, or similar.
• Comfort with Git and pull\-request workflows.
• Willing to hold a release. This role sometimes has to say a build is not ready while people are waiting on it. Saying so is the job.
• Able to work on\-site in Las Vegas full\-time, and authorized to work in the United States.

**Nice to Have**

• Experience testing AI or LLM\-generated output, or building and running eval harnesses.
• Exposure to regulated industries — medical device, pharmaceutical, clinical research — or to 21 CFR Part 11, GxP, or computer system validation.
• API testing and SQL fluent enough to verify data directly rather than only through the interface.
• CI/CD experience, particularly GitHub Actions.
• Accessibility testing, or performance and load testing.
• Experience establishing a test process somewhere that did not have one.
• Startup experience, including comfort operating before the process exists.

**How We Build**

• **Nothing ships on one good\-looking example.**

Every prompt, retrieval, or tool change is judged against a regression suite and a set of graded outputs before it reaches a customer. We iterate on numbers.

• **Fast loop to production.**

You will be testing against staging in your first week, and the bugs you file get fixed quickly enough that you verify them yourself.

• **You own a test surface end to end.**

From exploratory passes and the cases you write, through the automation and the defect trail, to confirming the fix in production. No one hands you a script to execute and takes the thinking back.

• **Small team, direct collaboration.**

You work alongside the founding engineering team, with code review on every pull request you open.

• **We build on the frontier.**

We track new model releases, context and caching capabilities, and agent tooling as they land, and rebuild around them when they are better. What you learn here is current.

**What Success Looks Like in This Role**

• Defects are found in staging, not by customers — and the escape rate is trending down.
• Fabricated, mismatched, or unsupported citations are caught internally before a customer ever sees one.
• A green regression run actually means something, because the suite covers what matters and is not flaky.
• Bug reports are acted on without a follow\-up question.
• Coverage gaps are known and stated in advance, rather than discovered by an incident.
• Model\-quality issues and code defects go to the right people the first time.
• Release decisions have evidence behind them, and engineering trusts your read.

**Why this role exists. **

Traditional QA assumes a correct answer you can assert against. Here the system writes something new every time, and the failure mode is a document that reads perfectly and contains a claim its own citation does not support. That is not a problem you solve by adding assertions — it needs someone who will read the output the way a regulator would.

That is this role.