对话B工：如何培养高效的测试分析思维习惯-CSDN博客

本文链接：https://blog.csdn.net/weixin_50271247/article/details/130733840

1 引言

前几天，有个叫B工（化名）的资深测试伙伴向我提了二个问题，如下

B工原是国内某大厂工作了10+年的高级测试架构师，2021年跳槽到一家做工控软件的公司负责近300人的软件测试团队的质量保障体系建设。

B工在大厂工作时，深感团队在达到一定规模后，标准化流程化作业带来的好处。于是加入新公司后，着手的第一件事情，就是梳理新团队的现况，把自己熟悉的一套流程规范融合到新团队，并在领导的支持下，尝试在各项目及各技术团队中推广落地。但一年多后发现效果并不理想。于是在2023年初调整策略，体系建设的事先聚焦在软件测试的某业务小团队上面，在深入过程中发现了上面的二个问题。

下面是我们俩的对话整理。

2 识别问题

我：“测试人员设计能力弱，没怎么做过针对实现逻辑的测试分析设计”，具体是什么意思。

B工：这边的测试人员，基本不做测试分析，没有输出测试方案，拿到需求后，直接输出测试用例。而我认为，这是不够的，是会导致考虑不全面的，特别是软件实现的逻辑，不进行测试角度的分析，容易造成漏测。

我：这的确是个问题。现在是组织没要求做测试分析，输出测试方案，还是你觉得员工没这个分析能力。

B工：应该两者都有。之前确实也是没这方面的要求，我来之后，首先就是创建各种规范化的测试方案、报告、用例模板，制定测试流程，并推动落地。现在的问题是落地效果不太好，原来做事情的习惯难于纠正。

我：这很正常，质量保障体系建设是一件需持续的长期坚持的事，涉及面广。不只是标准化流程化规范化的定义，还有非常核心的主体：人。在今年调整后的策略中，是选择哪些人作为体系建设落地的重点呢。

B工若有所思，沉默片刻后，答道：

的确没在这个维度单独拎出来考虑，现在主要是围绕事情，选择了一个重点项目的测试团队在推进。

我：选择重点项目推进，是一个很好的思路，因为重点项目中一般资源丰富，一旦落地成功，也会更有说服力。

B工：是的，我们也是这样考虑的。

我：重点项目中的测试团队有多少人，他们的能力素质情况，及具体做哪些任务是否清楚。

B工，又沉默了片刻，一会回答道：

大约有20多人，分别负责不同的业务模块，但他们的能力素质，及具体做什么工作，我的确不太了解。

我：B工了解公司的业务吗。

B工：业务非常多，只能算了解一些，有时会参加他们的需求、设计、用例评审。

我：B工是以什么角色参加他们的评审呢

B工：参加评审对于我来说，主要是想多了解业务，了解这个团队，以便创建适合团队的体系吧。

我：直接的来说，这是B工你的理解，但评审时，屋子里其他人并不一定是怎么想的，他们更希望参加评审的每一个人都能真正参与进来，给评审对象给出更多有意义有价值的反馈。所以，基于这一点，建议B工可以选择某一任务，与团队某人结对，按他们现有的流程完成几件有代表性的任务，过程中发现问题，及深入了解这个团队，才能与团队打成一片。

B工：沉默。

我：现在B工的身份与能力，只是领导认可，团队的成员都是在观望的。与团队打成一片，一方面是相互间增加了解，熟悉了好办事，二方面通过把自己匍匐到一线，把自己的技术、积累的经验真正体现出来帮到团队，取得他们的信任，这也是最快的方法。

B工：继续沉默。

我：匍匐到一线后，还有个好处就是你能快速熟悉业务，与团队有更多的共同话题，制定的模板，规范等，能更适合他们，甚至可以你来指导由他们完成，这样落地也就顺理成章的事了。

B工，似恍然大悟，说道：

是啊，大受启发，感谢感谢老师。这个体系建设，团队赋能的事，真不是一天二天的事。我一直纳闷，为什么他们就那么难改变思维习惯。

3 没有一成不变的方法

我：正常的，因为大部分人都会觉得现在并没有什么不好，只是领导基于各种压力，需要改革。

B：是这样。就问题二，老师有什么建议吗。

我：其实是类似的问题，还是需要B工深入地了解团队，才能更好的解决这个问题。由于此问题除了涉及测试团队，还关联开发团队，项目管理，部门管理，需要多方协商才能拿出合适的解决方案。

例如：站在测试人员的角度，因为现在的流程中增加了测试人员需输出测试分析的方案，而此输出需要依赖开发人员的设计方案作为输入，当条件不具备时，不少测试人员自然就会叫起来。

而站在开发人员的角度，虽然理论上他们是需要输出设计方案，但在版本发布的重压下，他们通常会选择画设计草图，找人讨论，然后直接写代码。直到版本发布后，再补充输出模板化的设计文档用于归档。那么这种情况测试人员如何解决问题呢，也是有办法的，例如主动参加开发的设计方案讨论，然后输出测试方案，对于不确定的地方主动找开发确认，也是可以解决的。

当然，有流程，大家按流程来做事是最好的。在我接触的过往项目中，大部分开发工程师，一般情况也是按流程完成任务的。

还有一个非常重要的问题，我们测试人员是否可让开发人员意识到，他们输出的设计文档是很有价值的，例如输出了，测试人员就一定可看懂，减少漏测。而现实中，往往是很多测试人员是看不懂开发人员画的类图，时序交互图等设计输出的，也就是还是要依赖开发人员给测试人员宣讲。

例如，就下面这个简单的登录窗口，