如何破除对测试人员的偏见

一、前言

我从事测试工作六年有余，开始不懂测试，后来去了某大型互联网公司做专项测试，一番锤炼之后，自认为知道了测试的精髓，然而其实只是管中窥豹，后来跳槽，周围人大部分是业务测试，以点点点之绝技闻名于互联网大染缸，我变得困惑，为啥像用户一样操作的方法能够存活在技术圈中，我开始怀疑测试，质疑测试，然后随着工作经历的增多，我又开始相信测试，测试是需要通过技术的手段去描述你的思想的行为，测试的底层操作是技术和思想，思想层面的事情，千人千面，各有论断，是非由他人评说。

二、 测试的现状

之前看过一篇文章，以佛家修炼三个境界开头，看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水，这么说感觉有点绕，但跟测试工作契合度是很高的，对于很多人来说，测试是无聊的，技术含量偏低，围着开发转，点点点的重复劳动，但随着工作阅历增加，我觉得测试越来越难，如何面对需求随意给，然后锅从天上来乱象，你去测试一个系统不了解其架构，语言，很多都是在表皮上测试，你如何保证测试覆盖率，我开始对各种开发语言进行了解，研究如何测试，随着接触行业前辈以及优秀的实践，理念逐渐的渗透，只从技术层面来看待测试还是不够的，测试是为质量负责，测试的中心是质量，没有质量意识测试没有灵魂，质量意识渗透到每一个环节和个人也是测试的使命之一。

三 、质量意识

个人认为，软件的质量最终检验标准是和真实需求是否高度契合，那如何渗透到每个环节和个人呢？

可能很多同学都听过测试左移这个词，那什么叫做测试左移呢？

n多年前，在软件开发过程中是没有单独的“测试阶段”，测试人员的角色根本就不存在。开发人员开发软件，然后测试，最后发布。

当缺陷开始占用项目的预算的时候，软件测试的概念逐步被引进，因此“功能测试”就造就了很小的测试团队。

IT行业开始使用瀑布模式，我们都知道，瀑布模式的软件开发生命周期是“需求”->“设计”->“编码”->“测试”。

所以，如果你是按照上面从左到右的顺序，那么测试阶段就是软件开发生命周期里属于极“右”的了。

测试左移的概念介绍

过去很长一段时间，人们意识到软件测试的重要性，以及极右或是说在软件开发周期的最后阶段保留“测试阶段”的影响力。之所以会发生这种是因为bug的成本在后期是非常高的，需要花费很多精力和时间去修复。甚至严重的情况是产品都不能按时发布，导致很大的损失

“缺陷越早发现成本越低”

意识到这个道理经历很大的教训，所以在软件行业一个巨大的革命应运而生，被叫做“测试左移”，它的意思是把测试阶段从右向左移或者说每个阶段都把测试和测试人员都参与进去。测试左移也意味着不是在最后阶段进行测试而是一直持续测试，在每个阶段都持续测试。

测试左移对软件开发有怎样的影响？

左移聚焦在使测试人员在全部和最重要的项目阶段参与进来。这就是测试人员把焦点从发现bug转移到bug的预防上，同时也驱动项目的商业目标。

左移提高测试重要性，使测试人员的角色和责任都有极大的提升。

随着测试团队的责任的提高，团队不在仅仅聚焦在“测试软件去发现bug”，而是积极团队合作，参与项目初始阶段的计划和建立强壮有效的测试策略，而测试策略又为团队提供好的测试领导力和指导，使团队聚焦在产品的长远的视角，而不仅仅是测试工作。

左移首先为测试人员提供了设计测试的机会，无论这些测试是被聚焦在客户的体验还是期望，也促使开发人员根据这些测试去开发软件以满足客户需求。

左移并不是仅仅是测试人员的事。向左移动，持续执行测试活动也使开发发挥身为代码所有者的主动性，提高测试责任。

左移也鼓励测试人员去适应行为驱动开发（BDD）和测试驱动开发（TDD），预防软件bug。

敏捷中的测试左移：同样左移也适用于敏捷团队，测试人员也和其他角色一样参加每天的站立会议，评审会议，这会使他们了解更多的产品信息，能够很好分析产品细节并做出反馈，预防bug。

总之测试左移需要测试人员“尽早参与”，尽可能参加每个阶段的讨论和团队合作，都能对最终交付产生价值，帮助项目提前识别风险并做减轻计划。

在左移中测试人员应该做哪些不同的事情？

在左移策略中，下面几点是测试人员应该做的几个关键因素

1)测试团队需要项目初始阶段尽早参与，以便更好的团队整合以及在软件开发的每个阶段对业务都能提供有用的输入。

2) 测试团队应该和业务&运营团队一起工作，这样对项目会得到更明确需求，提供清晰的观点，培养新人也更有针对性，对培训和测试工具需求也能提前准备。

3) 测试团队必须和业务人员在软件开发早期进行沟通，这样去获取对产品更清晰地认识，也可以制定统一的测试策略和计划去优化测试，分析测试环境的从属关系，需要的第三方应用以及准备健壮的自动化策略和框架，建立有效的测试数据管理计划。

4) 测试团队必须和其他团队成员一起，为团队提供较好的测试领导力和指导工作，使团队聚焦在产品的长远的视角，而不仅仅是测试工作。

5)需求是项目成功的关键和基础，好的需求就决定了项目的成功。在需求计划阶段，测试人员需要评审和分析模糊的、更加清晰地、完整的、可测的以及符合验收标准的等等需求。

同时也需要去识别有没有遗漏的需求，理解需求的关联性，实施相关测试策略。清晰地需求帮助软件“更快失败”，能尽早修复所有失败。

6) 用真实的栗子阐述功能会使需求更加明确和精细。

7) 测试人员需要定期参加设计评审会议，理解产品设计和结构，识别设计缺陷，建议不同的设计选项，相应的分解设计创建测试场景。

8)测试人员需要提前很好的执行静态测试（评审），在关键项目文档上提供反馈，所以可以预防缺陷，达到预防效果。

9)测试团队应该和设计、开发团队合作，测试团队提前提供测试场景，然后开发代码，处理所有可能的实时场景及业务流程。

10)测试团队不得不设计健壮的测试场景，因此只要一部分bug在测试过程中被发现，在测试阶段大部分的bug都被预防了。

11)测试人员必须尽可能早的去测试，无论是在独立的还是本地系统上，以至于缺陷不会在下个阶段出现。

针对测试人员关于测试左移概念关键是通过各种方式尽可能提前发现缺陷。

概括来说，测试左移流程是：

尽早发现bug，减少项目成本

一遍一遍持续测试，减少收尾阶段的bug

所有事情做自动化，尽早上线

聚焦在客户需求，提高客户体验

“测试左移”的概念给整个测试角色带来了巨大的转变。直到现在，测试不仅仅是“发现bug”，现在它已致力于“从早期bug的检测到预防”的一段旅程中，在这个过程中，测试人员能做到帮助产品表达需求，帮助开发理清需求为最佳实践。

那既然有了测试左移，有没有测试右移呢？

测试右移是上线后测试同学仍需要关注线上情况，不能认为功能上线测试同学就可以退出了。通过线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低。在开发设计时就要考虑预警功能，系统层（如cpu、内存问题）、应用层（如响应时间）、业务层（如注册率、交易量）等出现异常的时候通过邮件等方式发出预警，相关同学才能知道哪里出了问题。技术同学要比业务方先发现问题，如果业务方已经发现业务量明显下降，说明问题已经很严重了。你也许会问，这跟测试同学有什么关系呢？测试同学可以监督开发需要补充监控预警功能，同时可以提供监控指标。还有一个是关注线上业务及用户使用情况，更多地关注用户价值高、使用率高的功能，在用例中补充遗漏的场景，尽量多地覆盖这些功能。

这篇就聊到这里谢谢大家！