交付项目中 QA 的思辨悟

前言

当前业界对于软件测试和质量相关的讨论非常多，各种不同的声音也层出不穷，比如去测试人员、测试人员无用论、测试技术化、测试工程化、测试与质量赋能、敏捷测试、持续测试、全程自动化测试等等。可见测试工作和专业的测试人员已经处于了一个很大的漩涡里面。但是只要一个项目追求高质量，那么它一定需要实施大量系统化的专业的测试和质量工作。而这些大量系统化的测试与质量工作一定需要拥有专业知识的人员来做。虽然一些互联网公司或者某些项目号称可以在没有专业 QA 的情况下成功交付了，但是他们是基于一定的前提条件的，比如项目规模不大，团队的 BA 和 Dev 也拥有专业的测试与质量能力，他们也愿意做测试与质量相关的工作，并且时间资源也足够；或者项目质量要求不高，允许带着问题和风险上线；或者项目已经非常成熟了，并且测试、质量、基础设施相关的工作做得很好，只需要做一些维护和扩展工作；或者是一些还处在探索和实验阶段的项目等。但是对于一个追求高质量的项目，如果业务和开发人员没有测试与质量相关的专业技能，或者业务和开发人员不愿意并且没有时间做测试与质量相关的工作，在这样的约束条件下，团队是一定是需要专业的 QA 的。

人员与项目

一般在交付项目中，主要的人员包括 PM，UX，BA，DEV，QA 等主要角色，有些特殊的项目还会配有 DevOps 等其他角色。基于敏捷测试和质量内建的方法论决定了团队中每个角色都会对质量负责，但是落到具体的交付工作中，每种角色技能和工作内容还是有其专业侧重的技能，比如有些专业技能（比如测试分析与设计，性能测试等）是其他角色在短时间内很难学会并掌握的，甚至是其他角色不愿意学习的；有些具体的工作（比如编写测试用例，执行测试，编写自动化测试等）是其他角色不愿意做的。如果一个项目希望有一个良好的氛围和产出，每个角色都应该愿意并且高效的使用自己所掌握的技能，但是不同的技能都是需要足够的时间来学习和磨炼的，所以一个角色很难有效的掌握大量的不同角色的技能，毕竟大家的时间都是一样的，一般人都会顾此失彼。对于 QA 这个角色来讲，现在很多项目都在尝试减少或者去掉，因为他们的项目满足前面提到的那些前提条件。相反如果一个项目不符合那几种情况，我建议一定要配有专业的 QA 人员。根据团队人员能力，项目类型，规模和质量要求的不同，需要的 QA 人员能力级别和数量都是不同的。由于这个问题的约束条件比较多，为了方便讨论，需要简化它们，比如一个中小等规模的团队（10-20 人左右），一个全新开发的保险项目，无法在交付前实施线上真实用户测试，质量要求很高，开发周期 1 年，并且需求是在开发过程中持续确定并有少量变化。项目各种角色都有，包括 PM，PO，UX，BA，DEV，QA，其中 QA 至少一个 Senior QA 或者 Lead QA，其他 QA 可以是普通级别的 QA。在这样的前提约束条件下，如果想 QA 能比较全面的实施敏捷测试和质量内建的相关工作，包括高覆盖率的功能自动化测试，QA 和 Dev 的比值应该是 1:3 左右，随着比值的减少即 QA 资源减少，导致 QA 相关的工作内容就需要随之减少，或者由其他角色来做，可以减少的工作包括有全面深入的探索性测试，性能测试和安全测试以及一些不重要的自动化测试开发等。而当这个比值达到 1：5 左右的时候，就达到了一个自动化功能测试的极限值，随着比值继续减少，自动化功能测试的开发工作也要随之减少。当这个比值减少到 1:10 的时候，QA 人员几乎没有时间来实施自动化功能测试，因为常规的测试和质量相关工作已经占用了绝大部分时间，所以基本上所有的自动化功能测试相关的工作基本上都需要交给开发人员来实施。但是一些特定测试，比如性能测试仍然需要 QA 人员来实施，并且也只能实施主要的性能测试用例，无法全方位实施全量的性能测试。（以上比值都是我多年工作的经验总结值。）日常最主要并且工作量最大的工作包括：测试策略与测试架构的设计和实施，测试流程的实施和管理，测试分析与测试设计，测试用例执行（包括手动和自动化）。对于大型的团队，还需要对团队进行测试赋能，甚至建设质量体系。（其中冰玉老师的敏捷测试文集，洞见的敏捷测试文集以及我写的ThoughtWorks的敏捷测试实践都非常全面的介绍了敏捷团队中 QA 所需的技能和日常的工作内容）对于一个以业务复杂度为主的业务系统，如果团队没有人力资源来实施自动化测试，这种情况下可以引入外部 contractor 来执行手动功能测试的工作。但是测试分析和测试设计的工作一般还是需要内部员工来实施，一般的团队最好是 QA，也可以有具备相同能力的 BA 和 Dev 来实施，比如在某大型通信厂商，很多项目的测试分析和测试用例的设计工作是由高级系统工程师来完成的，并不是测试与质量人员。如果改变了这些约束条件，那么 QA 人员的比例需要进行一定的调整，但是最重要的一条还是质量要求的高低。只要项目的质量要求高，就一定要有足够的时间，实施足够的测试与质量相关的专业工作，并且最好是由专业的 QA 人员来实施。如果没有专业的 QA 人员，就需要拥有足够专业技能的其他角色兼职来做，但是兼职的这个人其实就是一个 QA。

培养与管理

在实施敏捷测试而没有专门的 QA 部门的公司里面，对于初级 QA 人员的培养一直是一个很大的问题。由于没有专门的 QA 团队，每个 QA 分散在不同的团队。如果这些 QA 已经拥有的足够的专业技能和独立工作能力，那么他们一般都很好的完成工作，但是对于初级的 QA 人员，一般都不具备足够的专业技能和独立工作的能力。而这样的工作环境往往让他们感到沮丧和举步维艰，甚至放弃 QA 这份工作。如果能对这些初级的 QA 进行全面的系统化的持续的专业技能培训，工作方法的指导以及困惑的解答，可以极大的降低他们遇到的阻力和困惑，并且给予他们足够的能力和信心来完成工作。而要完成这样的培训和持续指导，是需要一个部门的概念来实施的。比如组织了一个虚拟的 QA 部门，由这个虚拟的 QA 部门统一来实施这样的培训，并且培训的讲师都是公司内部最有经验的 QA 人员。其次对于 QA 人员成长除了系统化的培训，还需要有专业的人，在专业的方面持续提供辅导和帮助，以及职业生涯的规划。这项工作的重要性直接决定了 QA 人员的发展和职业生涯，甚至改变对 QA 工作的看法，有可能让本想放弃的 QA 喜欢上 QA 这份工作。在我见过的很多公司里面，这个工作一般由部门的 QA Manager 或者 Portfolio Manager 来做。其次公司应该有相应的标杆职位以及相应的晋升通道，这样 QA 才能有相应的目标，从而可能产生更强的自驱力来学习，成长和工作。管理 QA 人员，如果是内部员工，可以通过体系化的培养体系使其成为一个对于我们合格的 QA，并且通过持续化的 Coach 可以使他们可以很好的完成相应的工作。但是对于管理 Contractor QA 会是一件困难的事，首先一般情况下 Contractor 都是临时加入的，且变动的可能性很大，导致很难持续的体系化的培养他们，从而很难让他们完成我们认为合格的 QA 能完成的相关工作。其次如果 Contractor 的能力无法满足工作需要，则只能交与一些基础的测试工作给它们，比如一些手动测试执行这样的简单工作。但是在标准的敏捷测试体系里面，手动测试执行这样的工作并不是主要的工作，从而导致能力不足的 Contractor QA 很难有用武之地。除非项目的自动测试的覆盖率极其低或者不高，并且项目的质量要求又高，这样的情况下大量的 Contractor QA 才有其高效的用武之地，用来做大规模的功能验证测试和回归手动测试。如果 Contractor QA 的能力足够，那么直接或者通过系统化的培训后，也是可以让其做和内部 QA 一样的工作。所以根据不同的项目情况和 Contractor QA 的能力高低，是否选用 Contractor QA 可能会得到一个不同的答案。如果项目人力资源严重不足的情况下，也无法招聘到足够的 QA ，则只有使用 Contractor QA。这个时候可以把 Contractor QA 分为两类，第一类只做手动测试的执行，如果项目有大量的手动测试需要执行；第二类是有较好的测试与质量技能，则对其进行体系的培训，使其能做敏捷测试与质量内建体系中一个 QA 需要完成的工作，从而解决人力资源问题。对于让 Senior QA 完成用例分析和用例设计工作，然后招聘 Contractor QA 来手动执行测试用例，或者要求 Junior 的 Dev 来实现自动化测试用例。这样的工作模型我认为是工作的。首先现在很多大型企业都是这样的工作模式，但是这样的工作方式效率比较低下，其次是用例的管理和传递问题。对于大量的测试用例，如果写得非常细节，到操作步骤级别，有可能一次流程的更改就是一次噩梦，但是如果只写测试点，又没有更为详细的业务流程或者用户流程，那么知识传递就可能出现很多遗漏和误解，导致大量的漏测和误测，测试有效性很低。为了解决这个问题，可以尝试以敏捷测试中的测试左移结合活文档给出了一些建议和改进方案。在敏捷测试里面我们建议的用例是基于业务流程或者用户行为来进行描述（参见我的文章测试用例的编写和管理和播客质量三人行之测试用例），从而降低维护成本。但是基于用户行文的方式也存在一个问题，那就是执行测试或者对测试进行自动化的需要了解一定的项目背景，业务知识才能读懂测试用例。因此这种工作方式能有效执行下去的前提条件是：对于需要 Contractor 进行手动测试的情况，首先项目需要有大量的人力和时间资源编写足够覆盖率的基于详细测试步骤的测试用例，并且没有人做自动化测试，全部是人工测试。项目允许测试时间很长，以及在项目有变动的时候能投入足够的人员资源和时间来对测试用例进行大量的维护工作，最终项目能接受这种低效率的工作方式。对于需要 Junior 的 Dev 编写自动化测试用例，首先需要编写足够覆盖率的基于领域语言和业务行为的测试用例，其次一定需要对这些 Dev 进行项目业务和技术相关的培训，让他们基本掌握项目的业务知识、领域语言、技术栈等，编写用例的人员还需要经常和这些 Dev 进行沟通，只有这样他们才能有效的开发自动化测试。对于第 1 种模式，它需要大量的时间，并且投入资源大，并不适合敏捷项目，更适合那种人力和时间资源丰富的大型产品项目。而对于第 2 种模式，投入资源也是比较大的，不过只要项目人力资源足够，对于敏捷项目也是可行的。并且这两种模型能工作还有一个共同的前提，就是从公司、部门到团队都认可测试分析和测试设计的重要性，并且认可测试用例是和产品代码一样重要、一样有价值的产出，从而让 QA 能感受到其工作产出的价值，从而获得足够的成就感。

质量与度量

对于软件的质量高低，一般的评价主要是 Bug 多不多，稳定不稳定，好不好用，快不快。但是传统的标准很难在开发过程中或者开发结束的时候确定，它们很有可能需要在产品环境被真实的使用后，或者是大规模的使用后才能度量。所以这样的度量对于一个单纯的交付而不维护产品的团队的帮助有限，如果交付团队的测试和质量工作又做得不足也不专业的情况下，只有这些标准的度量有效性不高。所以为了有效的度量交付团队的质量，我们需要使用到内部质量和外部质量的概念，并且要分定性分析度量和定量分析度量，并且根据不同的项目各自情况，定制化一套度量体系。（更多内容参见测试与质量成熟度模型和晓南老师关于质量度量的文集）

总结

对于 QA 来讲，其存在最主要的目的就是帮助项目提升和保证质量，从而满足项目的质量要求。而一个 QA 引以为傲的就是帮助项目获得高质量的结果。如果一个项目本身对于质量的要求很低，从而不会在测试与质量工作上，以及 QA 人力资源进行足够的投入，从而导致项目上少量的 QA 在工作上举步维艰，从而缺乏安全感和成就感，所以一个对于质量要求低的项目是可以不需要 QA 的。但是对于质量要求高的项目，要么给予足够的 QA 资源的，不管是内部员工还是 Contractor；要么不能给予足够的 QA，就需要给予足够的时间资源，实施了高度的质量内建实践，并且所有角色都需要分担所有需要做的测试与质量的工作，只有这样才能有效的保证项目高质量这个产出结果。术业有专攻，专业的事还是留给专业的人来做，不仅是为了获得更好的结果，而且还是为了节约时间。