测试工程师

每次发版都点一遍同样的流程,确认过去能用的东西没坏。

把需求变成用例,把用例变成在流水线里跑的脚本。

试那些没人写进需求的事:奇怪的输入、竞态、先做第三步再做第二步的用户。

权衡未修的 bug、风险、截止日期和业务,说「行」或「不行」。

评估输出不确定的软件 —— 构建评测集、捕捉行为回退、测试有害输出。

● 本职业有 1 条已核实事件,按真实发生日期标在轴上 —— 靠近标记的那几段曲线是有可核对的东西锚定的。

一家公司,对既有单元测试类做改进并经构建/通过/覆盖率过滤;生成用例 75% 可构建、57% 稳定通过、25% 提升覆盖。公司自撰论文;场景是限时测试马拉松而非日常流水线。

真实场景里的小规模试验。说明落地条件正在被检验,不代表条件已经成立。

以手工测试身份入行是本站上最弱的入口,因为那正是走得最快的任务。改为从对抗性思维和那门新学科进入:学会去弄坏没人规定过的东西,学会评估基于模型的系统 —— 那里几乎没有有经验的人,而团队正在招。会写代码现在是这个角色的基线,而不是它内部的一个专长。

如果你的一周主要是回归和脚本维护,这个角色正在你脚下被合并,你应该在它推动你之前先动。你真正的资产是你脑子里那个「这个产品会怎么坏」的模型;把它变成探索性测试、发布判断,以及对你团队几乎一定在加的模型类功能的评估。这些是资深位置,而且正被最先认领的人填上。

调整职责

从执行测试到拥有质量

总得有人来定义「测够了」是什么意思、掌握发布决定、并负责探索性工作。这个角色会留下;执行角色不会。

调整职责

专攻模型类系统的评估

它是新的、稀缺的,而且与测试人员已经在做的事直接相邻。发布模型类功能的团队需要一个假定它坏了的人。

相邻转岗

转测试开发或平台工程

构建让整个团队都能测试的流水线、环境和工具,是需求稳定的工程工作,而且用得上测试人员对「哪会出错」的了解。

手工测试执行是,而且很快。质量作为一门学科不是:仍然要有人想象系统会怎么失败、决定它是否准备好了、并且 —— 越来越多地 —— 评估行为不确定的软件,而这件事几乎还没人会。这份工作正从执行测试转向拥有风险,从断言固定输出转向评估行为。完成这个转变的人比过去的测试人员更值钱;没完成的人会发现角色在自己周围被合并掉。