当前业界对于软件测试和质量相关的讨论非常广泛，各种不同的声音此起彼伏。其中包括质疑测试人员的必要性、去测试人员化、强调测试技术化和工程化、探讨测试与质量的协同作用、讨论敏捷测试、持续测试以及全程自动化测试等等。
这些讨论表明，测试工作和专业测试人员已经陷入一个广泛而深入的漩涡中。
然而，只要一个项目追求高质量，就需要实施大量系统化的专业测试和质量工作。这些大量系统化的测试与质量工作需要专业知识的人员来完成。
尽管一些互联网公司或某些项目声称在没有专业QA的情况下成功交付，但这是建立在特定前提条件下的。例如：
- 项目规模较小，团队的BA和Dev具备专业的测试和质量能力，他们愿意承担测试和质量相关的工作，且有足够的时间资源；
- 或者项目对质量要求不高，允许在存在问题和风险的情况下上线；
- 或者项目已经非常成熟，测试、质量和基础设施工作得到有效执行，只需要进行一些维护和扩展工作；
- 或者项目仍处于探索和实验阶段；
- ...
然而，对于追求高质量的项目，如果业务和开发人员没有测试与质量相关的专业技能，或者业务和开发人员没有时间或不愿意进行测试与质量相关的工作，那么团队就需要专业的QA来帮助解决这些约束条件。
每种角色都有侧重的技能
在项目交付过程中，主要的参与人员通常包括项目经理（PM）、用户体验设计师（UX）、业务分析师（BA）、开发人员（DEV）、质量保证人员（QA）等核心角色。在某些特殊项目中，还可能会涉及到其他角色如DevOps等。
敏捷测试和质量内建方法论决定了团队中每个角色都对质量负有责任。然而，具体到实际的交付工作中，每个角色都有其专业性和侧重点。例如，某些专业技能（如测试分析与设计、性能测试等）在短时间内其他角色很难学习和掌握，甚至他们可能不愿意学习；而某些具体工作（如编写测试用例、执行测试、编写自动化测试等）可能是其他角色不愿意承担的。
在团队协作中，合理分配任务和角色的专业性是至关重要的。每个角色应发挥其专业技能，以确保交付的质量和可靠性。通过充分利用各个角色的专长，可以实现协同合作和有效的交付过程。团队成员应相互理解和尊重彼此的专业领域，并在合适的情况下进行协作和知识分享，以提高整体交付质量。
如果一个项目希望建立良好的团队氛围并提高产出，每个角色都应愿意并能够高效地运用自己所掌握的技能。然而，不同的技能都需要足够的时间来学习和磨练，因此一个角色很难有效地掌握大量不同角色所需的技能。
毕竟，大家的时间都是有限的，一般人都会在不同技能之间做出权衡。并且每个人应专注于自己的领域，并在该领域内精益求精。通过发挥各个角色的专业性，团队能够形成互补，从而提高整体的效能和成果。团队成员应该相互支持和合作，尊重彼此的专业领域，并在需要时进行知识共享和协作。
对于QA这个角色来说，我们很多项目都在尝试减少或去掉QA，因为这些项目满足之前提到的条件。然而，如果一个项目不符合这些条件，我建议一定要配备专业的QA人员。
QA 能力和数量要根据项目要求来配备
根据团队成员的能力、项目类型、规模和质量要求的不同，需要的QA人员的能力级别和数量会有所变化。
考虑到问题的复杂性，我们可以简化条件，以一个中等规模的团队（约10-20人）、全新开发的保险项目为例。该项目无法在交付前进行线上真实用户测试，质量要求高，开发周期为1年，需求在开发过程中持续确定并略有变化。项目涉及各种角色，包括项目经理（PM）、产品负责人（PO）、用户体验设计师（UX）、业务分析师（BA）、开发人员（DEV）和质量保证人员（QA）。其中，QA角色至少需要一名高级QA或领导级QA，其他QA可以是普通级别的。
在这样的约束条件下，如果希望QA能够全面实施敏捷测试和质量内建的相关工作，包括高覆盖率的功能自动化测试，QA与Dev的比例应大致为1:3。随着比例的减少，即QA资源的减少，相关工作的内容也需要相应减少，或由其他角色承担。可减少的工作包括全面深入的探索性测试、性能测试、安全测试以及一些不重要的自动化测试开发等。
当比例达到大约1:5时，就达到了自动化功能测试的极限。随着比例进一步减少，自动化功能测试的开发工作也将减少。当比例降至1:10时，QA人员几乎没有时间来进行自动化功能测试，因为常规测试和与质量相关的工作已占据了绝大部分时间。基本上所有自动化功能测试相关的工作都需要由开发人员来实施。然而，某些特定测试如性能测试仍需要QA人员来执行，尽管只能实施主要的性能测试用例，无法全面执行全量的性能测试。（以上比例是基于多年工作经验总结得出的）
日常工作中，主要且工作量最大的任务包括测试策略和测试架构的设计和实施、测试流程的实施和管理、测试分析与测试设计、测试用例的执行（包括手动和自动化）。对于大型团队，还需要为团队提供测试赋能，甚至建立质量体系。其中我们共同编写的《Thoughtworks 质量体系白皮书》以及我写的《Thoughtworks的敏捷测试实践》都非常全面地介绍了敏捷团队中QA所需的技能和日常的工作内容）
对于一个以复杂度为主的业务系统，如果团队没有足够的人力资源来实施自动化测试，可以考虑引入外部资源来执行手动功能测试。然而，测试分析和测试设计的工作通常需要由内部员工来完成。在一般团队中，最好由QA承担该角色，也可以由具备相同能力的BA和DEV来担任。例如，在某大型通信厂商中，许多项目的测试分析和测试用例设计工作由高级系统工程师完成，而不是测试与质量人员。
如果更改这些限制条件，需要对QA人员的比例进行一定的调整，但是最重要的是项目的质量要求。只要项目的质量要求高，就必须拥有足够的时间和专业工作来进行测试和质量相关的工作，最好是由专业的QA人员来实施。如果没有专业的QA人员，则需要具备足够专业技能的其他角色兼职，但是兼职的这个人其实就是一个QA。
QA 的培养与管理
在没有专门的QA部门但实施敏捷测试的公司中，培养初级QA人员一直是一个重要的挑战。由于没有独立的QA团队，每个QA成员分散在不同的团队中工作。如果这些QA已经具备足够的专业技能和独立工作能力，他们通常能够很好地完成任务。然而，对于初级QA人员来说，他们往往缺乏足够的专业技能和独立工作的能力。这样的工作环境常常使他们感到沮丧和面临困境，甚至可能放弃从事QA工作。
如果我们能够对这些初级QA人员进行全面系统化的持续专业技能培训、工作方法指导以及解答困惑，就能极大地降低他们面临的阻力和困惑，并给予他们完成工作所需的足够能力和信心。
要实现这样的培训和持续指导，需要建立一个部门的概念来负责执行。例如，设立一个虚拟的QA部门，由该部门统一实施培训，并由公司内部经验最丰富的QA人员担任讲师。此外，除了系统化的培训，QA人员的成长还需要专业人士提供持续的辅导和帮助，并进行职业生涯规划。
这项工作的重要性直接影响着QA人员的发展和职业生涯，甚至有可能改变对QA工作的看法，从而让原本打算放弃的QA人员喜欢上这份工作。在我所见过的许多公司中，这个工作一般由部门的QA经理或项目组合经理负责。其次，公司应该设立相应的标杆职位和晋升通道，为QA人员提供明确的目标，从而激发他们更强的自我驱动力，学习、成长和工作。
对于管理QA人员而言，如果他们是公司内部员工，可以通过建立系统化的培养计划，将他们培养成为符合我们要求的合格QA，并通过持续的辅导和指导确保他们能够很好地完成相应的工作。然而，管理外部QA人员会面临一些困难。首先，通常情况下，外部QA人员都是临时加入的，且可能存在较大的变动性，导致难以持续系统地培养他们，使他们能够胜任符合我们要求的QA工作。其次，如果他们的能力无法满足工作需求，那么只能将一些基础的测试工作交给他们，比如一些简单的手动测试执行工作。
然而，在标准的敏捷测试体系中，手动测试并不是主要的工作内容，这使得能力不足的外部QA人员很难发挥作用。除非项目的自动化测试覆盖率极低或者不足，同时项目对质量的要求很高，此时大量的外部QA人员才可能在大规模的功能验证测试和回归手动测试中发挥高效的作用。如果他们的能力足够，经过直接或系统化的培训后，他们也可以胜任与公司内部QA相同的工作。
因此，根据不同的项目情况和外部QA人员的能力水平，是否选择外部QA人员可能会得到不同的答案。在项目人力资源严重不足的情况下，无法招聘到足够的QA人员，只能选择使用外部QA人员。这时可以将外部QA人员分为两类：第一类只负责手动测试的执行，特别是在项目有大量手动测试需要执行时；第二类具备较好的测试和质量技能，通过系统化的培训使其能够完成敏捷测试和质量内建体系中一个QA所需完成的工作，从而解决人力资源问题。
解决测试用例的管理和知识传递问题
Senior QA负责用例分析和设计工作，然后招聘外部QA来执行手动测试用例，或者要求初级开发人员来实现自动化测试用例。这种工作模型在不少大型企业中被广泛采用，但效率较低，同时存在用例管理和传递的问题。
对于大量测试用例，如果编写得非常详细，甚至到操作步骤级别，一旦流程发生变更就会变成一场噩梦。但如果只写测试点，缺乏更详细的业务或用户流程描述，知识传递可能存在遗漏和误解，导致大量遗漏和误测，降低测试的有效性。
为了解决这个问题，可以尝试结合敏捷测试中的测试左移和活文档的方法提出建议和改进方案。在敏捷测试中，我们建议基于业务流程或用户行为来描述测试用例（参见我的文章测试用例的编写和管理和播客质量三人行之测试用例），以降低维护成本。然而，基于用户行为的方式也存在一个问题，即执行测试或进行自动化测试需要对项目背景和业务知识有一定的了解才能理解测试用例。
因此，这种工作模式能够有效执行的前提条件是：对于需要外部手动测试的情况，首先需要项目投入大量人力和时间编写基于详细测试步骤的测试用例以实现足够的覆盖率，并且没有人从事自动化测试，全部依靠人工测试。项目需要允许长时间的测试，并且在项目变更时能够投入足够的人力资源和时间来维护测试用例，最终项目能够接受这种低效率的工作模式。
对于需要初级开发人员编写自动化测试用例的情况，首先需要编写基于领域语言和业务行为的测试用例，以实现足够的覆盖率。其次，需要对这些开发人员进行项目业务和技术相关的培训，使他们基本掌握项目的业务知识、领域语言和技术栈等。编写用例的人员还需要与开发人员保持经常沟通，只有这样，开发人员才能有效地开发自动化测试。
对于第一种模式，它需要大量时间和资源投入，不适合敏捷项目，更适合人力和时间资源丰富的大型产品项目。对于第二种模式，资源投入也较大，但只要项目的人力资源足够，对于敏捷项目也是可行的。而这两种模式的共同前提是，公司、部门和团队都认识到测试分析和设计的重要性，并认可测试用例与产品代码一样重要、有价值的产出，从而让QA人员能够感受到他们工作产出的价值，获得足够的成就感。
总结
对于QA角色而言，其主要目的是帮助项目提升和保证质量，以满足项目的质量要求。一个QA引以为傲的是能够帮助项目取得高质量的成果。
如果一个项目本身对质量要求很低，不愿在测试、质量工作和QA资源上投入足够，那么少量的QA在工作中多半会感到困难重重，缺乏安全感和成就感。因此，对于质量要求低的项目来说，可以不需要QA。但对于质量要求高的项目，要么提供足够的QA资源，无论是内部员工还是承包商；要么如果无法提供足够的QA资源，就需要提供足够的时间和其他角色的人力资源，实施高度的质量内建实践，并让所有角色分担所有必要的测试和质量工作，只有这样才能有效保证项目以高质量的结果呈现。
专业事务需要专业人士来处理，这不仅能获得更好的结果，还能节约时间。
