测试工程师 · 任务逐条

手工回归测试

脚本化回归本来就可以自动化;变化在于智能体现在能按自然语言描述操作真实界面,并在界面变化时自行修复脚本 —— 这拿掉了过去让团队停留在手工测试上的维护负担。这是大多数 QA 岗位里最大的一块工时,而且走得很快。

这明确是多数 QA 岗位里最大的一块工时。剩下的任务里,没有一项大到能吸收那些一周全靠它填满的人。

编写测试用例与自动化脚本

从需求或代码本身生成测试,是代码生成工具最有效的用法之一,过去要一个迭代才能达到的覆盖率现在一个下午就出来了。生成的测试和生成的代码一样浅 —— 它们确认代码「做了什么」而不是「应该做什么」—— 所以下一项任务变得更重要。

生成的测试确认的是「代码做了什么」,不是「代码应该做什么」。用覆盖率而不是缺陷来衡量的团队会认定这件事已解决 —— 那是一个伤害测试人员的度量问题。

探索性与对抗性测试

生成的测试来源于需求或代码,所以和它们有同样的盲区。找出没人想到的失败,需要一个关于真实用户和真实系统如何出错的模型,它来自对这个产品、这个领域的经验。工具扩大了搜索范围;「往哪找」的假设仍然是人的,而昂贵的 bug 就在那里。

「该往哪里找」的直觉,是靠做那些正在消失的回归工作练出来的。护住这项任务的是一种流水线不再生产的经验。

决定能不能发

这是一个有组织后果的担责决定,团队没有表现出任何委托它的意愿。看板汇总状态;而「这次发布、这批客户、这一周能承受多大风险」的判断,由一个团队信任其判断的人来做。

在很多团队里,这个决定属于研发经理,不属于测试。在那些团队里,护住它护住的是别人的工作。

测试内含模型的系统

大多数新产品有模型在环,无法用「断言固定输出」来测试。评测设计、对抗性提示、行为回归是一门从业者稀少的新学科,而 QA 的思维方式 —— 假定它坏了、找出怎么坏的 —— 可以直接迁移。

「从业者很少」是对当下的描述。这门学科还太年轻,最终会有多大没人知道 —— 它也可能最后长在模型团队里,而不是 QA 里。