低测开比下的质量保障

在做网易有数的的时候，由于一些原因，我们很长一段时间都只有1个QA同学。当时研发人员大概是20多个，也就是测开比1:20。我们现在做严选的数据，有两个QA人员，测开比大概1:15左右，同时我们同一时间进行中的数据产品就有6、7个，还有数仓和数据服务（见下图）。

在这么低的测开比下，我们如何保障质量。我们会让产品、研发都参与到测试当中。但是只是把原来测试做的工作转嫁给产品和研发，就能解决产品质量的问题吗？

如何在低的测开比下保障好产品质量？下面我将分享下我们在实践中的经验总结。

质量是整个团队事情，并不是只是QA的责任。产品提需求，需求的质量，直接影响产品的质量。研发写代码，代码的质量，也直接影响了产品的质量。产品和研发决定了产品的质量，让测试负责产品的质量，本身就不合理。质量由整个团队负责，说起来容易，但执行起来就没有明确的主体了。所以我们必须明确团队中每个角色在质量方面的职责。

1. QA是测试的服务提供者。QA人力很少的情况下，不可能再是具体的测试执行者，不可能再去回归所有的功能。QA会变成服务的提供者，帮助整个团队提高质量的意识和能力。QA要学习业界先进的测试方法，根据测试方法论和团队的实际情况，制定符合团队的测试流程。QA要引入和开发测试流程中需要的工具集，提供给产品研发人员。QA通过培训和教练的方式，提升整个团队的测试方法论，测试工具的使用能力，贯彻测试流程的执行。

作为服务提供者的QA应该具有教练的能力。在严选数据这边，由于产品非常多，QA人员只有非常核心的产品才会真正的参与，其他以教练的方式来提升产品研发团队的质量保障能力。

作为服务提供者的QA应该具有工具集的构建能力。QA除了构建常规的持续集成等测试工具集外，我这边讲下在我们的工作中做的一些特化的事情。在做网易有数的时候，由于有数本身是一个工具，灵活性很大，用户使用有数制作出什么样的报表难以预期。有数前期经常在上线后，有用户反映原来制作的报表现在有问题，而我们自己的测试集难以覆盖，所有用户的情况和未来产生的新的报表。测试就牵头和研发一起做了个自动化跑当前所有的图表并自动检测的工具。在严选有数这边，数据的质量问题比产品UI和逻辑上的质量问题更重要，为此QA人员牵头构建数据质量中心。在数据质量中心，QA担任的职责其实是产品经理、项目经理和测试开发。

2. 研发是责任主体和测试的执行者。研发的产出对质量的影响最大，所以研发是质量的责任主体。从研发的角度看，应该认为QA是给自己提供测试服务，帮助自己来保障质量。研发交付的应该是高质量的产品，而不是代码。在有数时，测试的执行基本都是研发在做，研发要根据测试用例自己完成测试工作。研发相对心高气傲，自己的测试当中发现自己尽然会犯很多低级的错误（是人其实都在所难免），会更加加强自己的质量意识，提高自己的代码质量。越是提前发现质量问题，解决的成本就越低，影响面就越窄。所以研发的质量责任意识提升，对整体的质量提升帮助非常大。

在研发作为测试执行者的过程，我们还发现很多其他的好处。研发在测试过程中，对产品更加熟悉，对产品需求的理解更加深入。研发对产品需求理解更加深入，让研发能够更多的参与到产品的设计，这是另一个话题，未来可以再分享。

研发自己测试，还能减少和测试的沟通成本。首先能减少跟QA讲解技术实现的沟通成本，原来由QA要先了解技术实现，才能更好的测试。其次QA需要跟研发讲解如何复现bug。

3. 产品经理是用例的设计者和测试执行者。在QA人员比率不是非常低的情况下，暂时不建议让产品经理来代理QA来写用例。在严选数据这边，产品非常多，每个产品QA写用例也不现实，所以我们后面会让产品经理来设计用例。

让产品经理设计用例能让产品经理从非正常使用路径来看自己的产品，对产品会有不一样的理解。产品经理最理解需求，可以自己根据产品需求和设计来设计用例。产品经理会大大减少跟测试的沟通成本，原来测试需要对产品非常的理解才能写出好的用例，产品经理需要与QA深入的沟通，才能将自己对产品的理解转移给QA。

以上就是我对低测开比下的质量保障的理解。当然并不是所有的场景都适合上面讲到的模式，特别是一些测试专业能力要求比较高的，比如安全测试、复杂的性能测试。