Quality Assurance Engineer

Job Description

QA Engineer

Quality Engineering · Testing a Platform Whose Output Is Generated

\n
• Function: Quality Engineering
\n
• Reports to: Engineering leadership
\n
• Location: Las Vegas, NV — on-site. This is not a remote or hybrid role.
\n
• Level: QA Engineer
\n
• Employment type: Full-time
\n
• Experience: Approximately 2–5 years in a software quality role
\n
• Work authorization: Must be authorized to work in the United States
\n

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.

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

2. Test Design and Regression Coverage

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

\n
• Write and maintain test cases and checklists covering core user workflows.
\n
• Own the regression suite the team runs before a release, and keep it current as the product changes.
\n
• Map coverage against the product surface and say plainly where the gaps are.
\n
• 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.
\n

3. Verifying Generated Output

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

\n
• Check generated deliverables for internal consistency — numbers, cross-references, section completeness, and formatting.
\n
• Resolve identifiers and references an agent produces back against the source of record.
\n
• 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.
\n
• Grade output against golden examples and feed the results back into the eval suite.
\n
• Design test approaches that work when the output is nondeterministic — where "did it produce the expected string" is the wrong question.
\n

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.

\n
• Isolate a minimal, reliable reproduction — not "it sometimes breaks."
\n
• Report with repro steps, expected versus actual, environment, and a severity you can defend.
\n
• Trace a defect back to the requirement or workflow it breaks.
\n
• 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.
\n
• Follow each one through to verification of the fix.
\n

5. Release Verification and Quality Signal

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

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

6. Test Automation

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

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

Our Stack

\n
• Backend: Python 3.12, FastAPI, SQLAlchemy 2.0, Pydantic v2, Postgres / SQLite, pytest
\n
• Frontend: React 19, TypeScript (strict), Vite, TanStack Router + Query, Tailwind, shadcn/ui, Vitest + RTL
\n
• AI: Frontier LLM APIs (Claude), MCP tool servers, RAG, eval harnesses and golden-output graders
\n
• Infra: AWS (ECS/EC2, ECR, SQS, S3), Docker, GitHub Actions
\n

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

\n
• Roughly 2–5 years in a QA, software quality, or test engineering role, testing a real product with real users.
\n
• Degree in Computer Science, Computer Engineering, or a related field — or equivalent practical experience.
\n
• 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.
\n
• Attention to detail that catches the value which is subtly wrong, not just the page that will not load.
\n
• Clear technical writing. We will read your bug reports more than your code.
\n
• Able to read a primary source — a spec, a standard, an API contract — and check an implementation against exactly what it says.
\n
• Methodical under ambiguity. You narrow a vague complaint into a minimal reproduction instead of escalating it as-is.
\n
• Hands-on experience with at least one testing framework — pytest, Vitest, Playwright, Selenium, or similar.
\n
• Comfort with Git and pull-request workflows.
\n
• 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.
\n
• Able to work on-site in Las Vegas full-time, and authorized to work in the United States.
\n

Nice to Have

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

How We Build

\n
• 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.
\n
• 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.
\n
• 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.
\n
• Small team, direct collaboration. You work alongside the founding engineering team, with code review on every pull request you open.
\n
• 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.
\n

What Success Looks Like in This Role

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

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.