QA 工程师

职位概述

Regara 是面向生命科学行业的临床与法规智能平台。医疗器械、制药和生物技术公司借助我们，在多个市场规划和准备产品上市所需的一切 — 法规策略、临床方案、研究报告和注册申报资料。

AI 就是产品本身。我们运营着一个自主智能体平台，它们调研实时数据、基于数据进行推理，并端到端地撰写完整的技术文档。这让质量成为一个真正困难的问题。输出是生成的而非固定的，同样的输入两次可能产生不同的文本，而最终产物是客户提交给监管机构的文件。

这份工作与大多数 QA 工作的不同之处。在这里，缺陷不是一个错位的按钮，而是一个错误的数字、一个缺乏依据的论断，或一条来源并未支持其引用内容的引文。生成的文档可能行文流畅、格式规范，却依然是错的 — 屏幕上不会有任何提示。在客户之前发现这些问题，就是这份工作。

这是一个专职质量岗位。我们招聘您，不是让您在测试周期之间开发产品功能，而是因为公司最难的质量问题需要有人全身心投入。您将端到端负责一个测试领域 — 从探索性测试和您编写的用例，到缺陷跟踪，直至在生产环境中确认修复。

您实际要做的工作

01 · 探索性测试与功能测试

像客户一样使用产品，然后去寻找它出问题的地方。

• 对任务调度流程、结果视图和管理工具开展功能测试和 UI/UX 测试。
• 探查边界情况 — 空状态、超大输入、中断的运行、权限，以及浏览器和视口差异。
• 测试客户实际使用的工作流程，而不仅仅是孤立的页面。
• 对每个版本重新测试，找出回归问题。

02 · 测试设计与回归覆盖

把您学到的东西变成可重复、能延续到每个版本之后的成果。

• 编写并维护覆盖核心用户工作流程的测试用例和检查清单。
• 负责团队在发布前运行的回归测试套件，并随产品变化保持更新。
• 对照产品全貌梳理覆盖范围，并明确指出缺口在哪里。
• 按风险而不是按测试难易程度确定优先级。一个对低风险部分覆盖详尽、对高风险部分毫无覆盖的套件比没有套件更糟，因为它看起来像是有覆盖。

03 · 验证生成的输出

这份工作中最有意思的一半，也是没有成熟方法可循的部分。

• 检查生成的交付物的内部一致性 — 数字、交叉引用、章节完整性和格式。
• 将智能体生成的标识符和引用与权威来源进行核对。
• 标记缺乏依据的论断、错误的出处归属，以及内容不支持所引陈述的引文。引文完整性是本产品最关键的质量属性。
• 对照黄金样例对输出进行评分，并将结果反馈到评估套件中。
• 设计适用于非确定性输出的测试方法 — 在这种情况下，“是否生成了预期字符串”是一个错误的问题。

04 · 缺陷报告与分级

缺陷报告本身就是交付物。写得让人无需追问即可着手处理。

• 分离出最小且可靠的复现路径 — 而不是“有时会出错”。
• 报告中包含复现步骤、预期与实际结果、环境，以及您能为之论证的严重级别。
• 将缺陷追溯到它所破坏的需求或工作流程。
• 区分代码缺陷与模型质量问题。它们由不同的人负责、以不同方式修复，分错一次就会浪费所有人一周的时间。
• 跟进每个缺陷直至修复得到验证。

05 · 发布验证与质量信号

总得有人能判断一个版本是否安全，并且判断正确。

• 执行发布验证，就某个构建是否可以发布给出清晰、有证据支持的判断。
• 持续跟踪质量信号 — 缺陷趋势、逃逸率，以及产品中哪些部分反复出现问题。
• 以书面形式向工程团队报告质量状况，包括没人愿意听的部分。
• 当某个版本走势不佳时尽早发出警报。迟来的警告几乎和没有警告一样。

06 · 测试自动化

把手动检查转化为自动运行的检查 — 在确实有回报的地方。

• 用 pytest 扩展后端覆盖，用 Vitest 和 React Testing Library 扩展前端覆盖。
• 为流量最高的工作流程编写浏览器级端到端测试。
• 保持测试套件接入 GitHub Actions，让失败在拉取请求阶段而不是合并之后暴露出来。
• 审慎地推进自动化。一个没人信任的脆弱套件，成本比它所取代的手动测试还高。

我们的技术栈

• 后端 — Python 3.12, FastAPI, SQLAlchemy 2.0, Pydantic v2, Postgres / SQLite, pytest
• 前端 — React 19, TypeScript (strict), Vite, TanStack Router + Query, Tailwind, shadcn/ui, Vitest + RTL
• AI — 前沿 LLM API（Claude）、MCP 工具服务器、RAG、评估框架和黄金输出评分器
• 基础设施 — AWS（ECS/EC2, ECR, SQS, S3）, Docker, GitHub Actions

我们不要求您全部掌握。您的大部分测试是针对应用而非代码库进行的 — 但当您追查缺陷根源时要读的、扩展自动化套件时要写的，就是这些。

任职资格

必备条件

• 约 2–5 年 QA、软件质量或测试工程相关工作经验，测试过拥有真实用户的真实产品。
• 计算机科学、计算机工程或相关专业学位 — 或同等实践经验。
• 能熟练阅读和编写至少一种编程语言的代码。Python 或 TypeScript 最贴近我们的技术栈，但 Java、C++ 或其他语言也都可以。
• 细致入微，能发现细微错误的数值，而不仅仅是无法加载的页面。
• 清晰的技术写作能力。我们读您的缺陷报告会比读您的代码更多。
• 能够阅读一手资料 — 规格说明、标准、API 契约 — 并严格对照其内容检查实现。
• 在模糊情况下有条理。您会把一个笼统的问题反馈缩小为最小复现，而不是原样上报。
• 至少使用过一种测试框架的实际经验 — pytest、Vitest、Playwright、Selenium 或类似工具。
• 熟悉 Git 和拉取请求工作流程。
• 敢于叫停发布。这个岗位有时需要在大家都在等待时说出某个构建尚未就绪。说出来，就是这份工作。
• 能够在拉斯维加斯全职到岗工作，并具备在美国工作的合法身份。

优先条件

• 有测试 AI 或 LLM 生成输出的经验，或搭建和运行评估框架的经验。
• 有受监管行业（医疗器械、制药、临床研究）的经验，或熟悉 21 CFR Part 11、GxP 或计算机化系统验证。
• 具备足够的 API 测试和 SQL 能力，能够直接验证数据，而不仅仅通过界面验证。
• 有 CI/CD 经验，尤其是 GitHub Actions。
• 有无障碍测试，或性能与负载测试经验。
• 有在原本没有测试流程的地方建立测试流程的经验。
• 有初创公司经验，能够在流程尚未建立时从容开展工作。

我们如何构建产品

• 不会凭一个看起来不错的例子就发布。每一次提示词、检索或工具的变更，在到达客户之前都要经过回归套件和一组已评分输出的检验。我们用数据驱动迭代。
• 快速进入生产。入职第一周您就会在预发布环境中测试，您提交的缺陷修复得足够快，您可以亲自验证修复结果。
• 您端到端负责一个测试领域。从探索性测试和您编写的用例，到自动化和缺陷跟踪，直至在生产环境中确认修复。没有人会递给您一份脚本让您执行，却把思考的部分收回去。
• 小团队，直接协作。您将与创始工程团队并肩工作，您提交的每一个拉取请求都会经过代码审查。
• 我们在前沿构建。我们第一时间跟进新模型发布、上下文与缓存能力以及智能体工具，一旦它们更好，就围绕它们重新构建。您在这里学到的都是最新的。

成功的标志

• 缺陷在预发布环境中被发现，而不是由客户发现 — 并且逃逸率呈下降趋势。
• 伪造、错误归属或缺乏依据的引文在客户看到之前就在内部被发现。
• 回归测试全部通过真正有意义，因为套件覆盖了关键内容且不存在不稳定性。
• 缺陷报告无需追问即可被处理。
• 覆盖缺口事先已知并已说明，而不是通过事故才被发现。
• 模型质量问题和代码缺陷第一次就交给了正确的人。
• 发布决策有证据支撑，工程团队信任您的判断。

为什么设立这个岗位

传统 QA 假定存在一个可以用来断言的正确答案。而在这里，系统每次都会写出新的内容，失败的形态是一份读起来毫无破绽、却包含其自身引文并不支持的论断的文档。这不是靠增加断言就能解决的问题 — 它需要有人像监管机构那样审读输出。这就是这个岗位。