交付项目中QA的思辨悟

前言

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

人员与项目

一般在交付项目中，主要的人员包括PM，UX，BA，DEV，QA等主要角色，有些特殊的项目还会配有DevOps等其他角色。基于敏捷测试和质量内建的方法论决定了团队中每个角色都会对质量负责，但是落到具体的交付工作中，每种角色技能和工作内容还是有其专业侧重的技能，比如有些专业技能（比如测试分析与设计，性能测试等）是其他角色在短时间内很难学会并掌握的，甚至是其他角色不愿意学习的；有些具体的工作（比如编写测试用例，执行测试，编写自动化测试等）是其他角色不愿意做的。
如果一个项目希望有一个良好的氛围和产出，每个角色都应该愿意并且高效的使用自己所掌握的技能，但是不同的技能都是需要足够的时间来学习和磨炼的，所以一个角色很难有效的掌握大量的不同角色的技能，毕竟大家的时间都是一样的，一般人都会顾此失彼。
对于QA这个角色来讲，现在很多项目都在尝试减少或者去掉，因为他们的项目满足前面提到的那些前提条件。相反如果一个项目不符合那几种情况，我建议一定要配有专业的QA人员。
根据团队人员能力，项目类型，规模和质量要求的不同，需要的QA人员能力级别和数量都是不同的。由于这个问题的约束条件比较多，为了方便讨论，需要简化它们，比如一个中小等规模的团队（10-20人左右），一个全新开发的保险项目，无法在交付前实施线上真实用户测试