“从对人负责的角度，重新理解每一个职业”

                                                                “当一群人深陷在自己的社会分工中，

                                                                只会对事负责的时候，

                                                                总会有另一群人觉醒过来，

                                                                能跨越出自己的社会分工，

                                                                对人负责。”

                                                                                            ——罗振宇，2021跨年演讲

        软件测试在一个项目中的确有很多事情要做，最基本的包括制定测试计划、编写测试用例、搭建测试环境、执行测试用例、报告测试结果等等。但是，软件测试的目的是为了对这些事负责吗？

        人们通常认为，软件测试就是验证软件产品特性是否满足用户的需求，或者就是发现软件产品中的bug。这都没有错，是正向和逆向两种思维方式，互为补充，发现软件中的bug也是从用户角度出发，找到对用户产生负面影响的缺陷。这样来说，其实软件测试从根本上不是对产品负责，也不是对bug 负责，而是对用户负责。

        如果对事负责，你会花很多时间去读需求文档，根据文档编写测试用例；

        如果对人负责，你会花很多时间研究用户，分析产品的目标用户，观察用户的行为，研究用户的应用场景。

        如果对事负责，你会视用户故事卡片、需求文档为圣旨，把它们作为测试的依据；

        如果对人负责，你敢于质疑用户故事的描述、需求文档是否完善，是否正确，是否代表了用户真正的需求。

        如果对事负责，你会按部就班的执行测试用例，每天完成多少条测试用例，每周提报多少个有效的bug；

        如果对人负责，你会在测试中扮演产品的用户角色，从用户出发设计不同的用户场景进行测试。

软件测试到底是一个职业还是一个角色？

        子曰：君子不器，出自《论语·为政》，意思是君子心怀天下，不像器具那样，作用仅仅限于某一方面。人一旦成为器物就会很脆弱，因为器物是有形的，有形的东西用途就是固定的，一旦情况发生变化，这种器物没用了，就会被抛弃。因此，人要具备反脆弱的能力，就不能让自己局限于只能做一种事。

        在传统的瀑布式软件开发模式中，开发和测试被分成两个不同的阶段，开发人员和测试人员的职责泾渭分明，做开发的只管编写代码，做测试的只管找bug。因此，传统模式下的研发团队中，既有专门的开发部门，也有专门的测试部门。在这样的体制下，软件测试被当成一项职业，一个社会分工。但开发和测试好歹还在一个研发团队里，负责需求的产品市场部门往往独立在研发团队之外，产品部门、开发部门和测试部门之间都有厚厚的墙，需求从墙外扔过来，产品从墙内扔出去。产品经理、开发人员、测试人员、项目经理这些角色都被禁锢在各自的系统里，都成为了工具人，互相也不了解各自的业务领域。

        敏捷开发模式让这个情况开始转变，打破了开发、测试和产品之间的墙，倡导这三者之间的彻底融合，大家组成一个全职能的敏捷团队，软件测试不再只是测试人员的责任，开发人员也要做测试，测试人员也要参与需求分析，产品负责人也要参与软件测试特别是验收测试。可以说，在敏捷模式中，软件测试不再是一项职业，而变成一个团队中的角色。显然，这对人的要求更高，但也有助于掀翻软件测试人员职业发展的天花板，充分调动和发挥团队中每个个体的潜能。

                               研发组织从传统向敏捷演化（以Scrum为例，来自朱少民的《高效敏捷测试》专栏）

我们是否常常困在自动化测试系统中？

        现在每个企业都有自己的自动化测试系统，在软件测试中引入测试自动化的目的当然是为了提高测试效率，提升产品或新的功能特性交付给用户的速度。但是，许多公司为了自动化而自动化，为了建测试平台而去建测试平台，重复造轮子的现象相当严重。作为测试开发人员，你是对自动化测试系统负责，还是对最终交付给用户的产品负责？是为了开发一个测试系统而开发，还是为了快速的向客户交付有价值的产品？

        如果困在自动化测试系统中，你会热衷于工具开发，重点关注的是开发一个功能强大的系统，你的目标是开展尽可能多的自动化测试。

        如果只把自动化测试作为手段，你会思考如何制定测试策略，什么样的测试采用什么样的测试方式，或者有时候采用手工测试也许效率更高？

        如果困在自动化测试系统中，你只会把手工测试用例“翻译”成自动化测试脚本，并不关心测试用例本身是否合理；

        如果只是把自动化测试作为手段，你会首先从业务出发，从满足用户质量要求的角度考虑测试覆盖率，先解决测什么的问题，然后再思考怎么测的问题。

我们是否常常困在测试流程里？

        从上个世纪后期到现在，软件测试经过几十年的发展，目前已经形成了完整的测试流程和体系。一开始没有流程的时候，大家都是摸索着前进，逐渐了形成了一套流程，又变得越来越重，传统的瀑布开发模式下的测试流程尤其如此，在此基础上，又发展出认证体系，比如TMMi认证。很多企业为了业绩和资质，全力以赴只为拿到认证。那么，我们到底是对测试流程负责，还是对流程中的自己负责？

        流程中必然包括针对软件测试的绩效系统，测试人员被要求一天执行多少条测试用例，一周提报多少个有效的bug。一套绩效体系被建立起来，这和要求外卖小哥多少分钟送达外卖很有几分相似。每个测试人员被困在绩效系统里，那么，他们是对绩效指标负责，还是对用户负责？一切的系统对我们来说，都只是工具，绩效看板让我们能够清楚的了解进度，计划和调整工作，但我们不是对绩效负责，而是对产品负责。

总结

        你还会困在这个软件测试的系统（方法、流程、工具）里吗？不，所有这一切，最终都是为了让用户满意，而这些只是工具。

        总体来说，传统的软件测试更重视流程，让人按照流程去做事，什么时候该做什么事，因此往往对事；而现代的敏捷测试更重视用户，因此往往对人。

        传统的软件测试构造出一个坚固的系统，把软件测试人员困在系统中，只能做测试流程中规定的测试人员该做的事，用固定思维来看待做事的人；而现代的敏捷测试坚定的要打破这个系统，不会把团队中的任何人固化在一个职业里，一个角色里，赋予个体更大的成长空间，鼓励个体的成长性思维和批判性思维。

        这代表了一种进步，但归根到底，能困住人的不是系统，而是人本身，你到底应该对事负责，还是对人负责呢？