每一段时间, 就会有人开始讨论QA的performance要如何评量, 有些人会提出以下的index
- 计算所找到的Bug个数
- 在一段时间内所开立的测试个案
- 所执行的测试个案个数
- 自动化测试个案个数/ 所有测试个案个数
- 测试涵盖度
这些index的缺点, 是缺乏考虑整个环境或是项目的状况, 容易会忽略一些会影响的变量. 作者认为如果没有根据context就来衡量个人的绩效, 是一件愚蠢的事情.
例如有些狡猾的测试人员, 可能会采取一些策略来达到你的index的标准, 但是却危害了整个团队的质量.举各例子来说: 如果manager说要评量engineer每周所找到的bug数, 并且订定每周的标准是10个bugs. 这时候会发生什么事, 每周engineers会想办法找到10个bugs, 但是对于多找的bugs, 有些engineers可能会考虑放到下周再提报出来, 这样才能确保下周他比较容易达到pass的criteria. 这代表bug report是无法反映实时的状况, 很能是慢一周. 所以你有可能会误解这时候状况不严重, 导致你会因为错误的数据而做出不当的决策.
为什么会这样呢? 主要是因为有些短视的人, 想要用简单的方法, 去解决困难的问题. 可是这个人绩效问题, 真的是没有简单的公式就可以衡量出来的. 而且有些衡量是很主观的, 并且也外受到一些外在因素的影响, 像是所处的工作环境, 或是使用的工具, 或是你本身的个性, 或是老板是否善于鼓励员工...等等, 这些因素都会让相同的人, 产生不同的结果.
另一个我常见的问题, 那是订定不切实际的目标. 像是"找出主要的bugs", 试问你如何界定他是主要的bug? 并且主要的bug是否代表就是重要的bug呢?
Over-promise和under-deliver也是个严重的问题, 没有根据自己的能力来订出适当的目标. 另一个相关的就是, manager给所有人都是相同的pass criteria, 既然每个人的能力不同, 你就必须要给每个人设定不同的标准.
作者建议测试人员试着要和你的经理, 去学习如何订定SMART的衡量标准. 因为每个人能力不同, 项目环境不同, 没有一体适用的标准. 此外也要记得align managers, product teams或是company的goal. (当然啊, 最后这点是比较争议的, 因为你的career path不一定和公司一样)
最新内容请见作者的GitHub页：http://qaseven.github.io/
