测试要不要向过程质量的探索？

　　上文定义了测试的本职工作。但是在实际的工作中，测试和过程质量之间的界限非常模糊，这是开篇提到的承担/推卸之间度的问题——承担额外的工作压力和责任，疲于奔命，无法把精力和心思放在提高本职工作，专注获取自我职业提升上。

　　没有一个标准答案，需要具体情况具体分析的判断。下面分别从三个角度来分析问题：

　　正面：

　　测试人员多是新人，打出bug之后，并不是继续投入到其他测试执行或者测试技能提升，而是继续跟踪这个bug，确认bug是那个开发人员的，这个开发人员怎么分析定位的，bug的原因是什么，业务逻辑耦合还是编码思路不够清楚，这个bug是怎么修复的，resolved之后，自己应该怎么验证？       通过这种对bug打破沙锅问到底的方式，测试人员能较为快速的了解很多业务逻辑，对后面自己定位问题、分析问题，甚至成长为需求、架构师都非常有帮助。当然，可能对测试本身来说较为耗时，因为同样的工作时间，可能会继续执行好多case。

　　测试人员是老手，对很多疑难问题怎么处理都比较清楚，甚至一些常见的编码错误都比较知道。所以会去对一些研发的新人做一些反向的追溯和建议。这种方式，对产品本身的质量非常好，同样，也很容易让开发和测试之间的对立关系趋向于平和。

　　反面：

　　真正需要对质量负责的人，逃避了自己的责任。某个产品经理面向客户一阵虚吹，回头给的项目时间比较少。后出了问题，直接找测试团队背黑锅，产品质量问题都是因为没有测出来。

　　没有真正意义上的QA团队，由测试团队兼任，在向前探索，规范过程的时候，和开发人员对立，然后把较多的精力放在互相证明对方是错误、是不规范的事情上。无法集中精力在业务和技术的层次——如果明确是测试兼任QA的职责，那么一定要快速的切成两只子团队，各负其责。职责混淆在一起，肯定会出问题。

　　第三方：

　　产品经理和测试主管达成一致，你帮我背黑锅，回头我补偿给你——某款产品出了问题，大老板雷霆震怒，一定要找人承担责任。这时候，产品经理说不能让全团队挂掉啊，测试的兄弟帮忙背个黑锅，回头我补偿你。然后测试主管站出来，说都是我的错。然后扣奖金，通报。过了半年，产品经理找个由头，给测试主管加了一下工资。

　　类似的这种小弟替老大背黑锅的江湖义气桥段，实际上在很多公司也上演过。这种场景不好定位是正方还是反方，所以放在第三方来描述。

　　所以测试要不要向过程质量去探索，甚至承担质量的责任。在不同的公司、文化、环境、定位下，是截然不同的选择。

　　很多迷茫的同行，也不要奢望能在网上找到标准答案。自己在工作的时候，仔细的评估好各种利害关系，小心求证的去做即是。

　　整体而言，产品的质量是产品团队每个人都要承担的，不隶属于某个小组或某个角色。测试的责任是要对测试工作本身负责，承担本职工作的质量责任，而不是承担整个产品的质量责任。让测试本职工作更专业的方法是去提高测试的效率、准确度、方法、工具、思路等等。