敏捷测试：从QC到QA

传统软件开发过程中，存在测试工程师岗位。通常测试工程师的定义是：指理解产品的功能要求，并对其进行测试，检查软件有没有缺陷，测试软件是否具有稳定性、安全性、易操作性等性能，写出相应的测试规范和测试用例的专门工作人员。测试工程师在工作中，从事的是QC（Quality Control ）的工作。这样经常会出现开发工程师和测试工程师之间的矛盾，还引发了“啄木鸟”奖之类的激化矛盾的产物，造成项目组内耗，浪费了人力物力以及时间。

在敏捷开发中提出了QA（Quality Assurance）的概念，主要职责是主导并促使跟质量相关的活动在团队内发生，包括但不仅限于测试。

那么，QC和QA有什么区别呢？

表1.QA、QC对比

从上表可以看到，QA和QC的目的不同，QA是跟软件开发站在一起的，为了提高软件产品的质量和开发效率服务的，而QC看起来站在软件开发的对立面，专门来为软件产品挑刺的。做好QC工作很容易，安静的给软件产品找缺陷，每个阶段做什么事情也有流程规范，照着做就行。可是做好了QC工作，对软件质量提升的帮助是很小的。我们都知道，质量是设计出来的，不是测试出来的。经过多轮回归测试，最后软件产品的缺陷满足了公司的缺陷率标准后，软件产品的质量有保障了吗？没有。如果需要经过超过一轮回归测试才能达到公司的缺陷率标准，很明显该产品的质量保证体系是很薄弱的，是不堪一击的。达到了公司的缺陷率标准，只不过因为还有缺陷没有被发现而已。好的质量保证体系，需要在一次回归测试就能够达到缺陷率标准，每次回归测试都在质量标准内。

所以，做好QA工作很难。在敏捷开发中，通常团队中的每个人都要参与QA工作，而每个团队中，都有一个人主要负责QA工作，这个人通常也被称之为“QA”。接下来聊一聊敏捷开发团队中的“QA”怎么去做好工作的。

“QA”需要有四个方面的特质：

1、善于沟通且乐于沟通。软件开发活动其实是一种社交活动，在社交过程中，知识进行了转移，最后开发团队成员掌握了相关的知识并且生成了知识的产物--可工作的软件。在敏捷开发中，QA需要从需求阶段就开始介入，在整个软件开发生命周期中都需要参加。敏捷软件开发强调质量内建，在用户故事的生命周期中，作为质量保障的主要负责人，QA需要在每个阶段跟不同的角色反复确认和验证，确保团队对需求理解一致，还要保证跟质量相关的活动发生，比如确保开发人员添加了相关的自动化测试，所以QA需要和团队的每一个成员以及客户有非常多的交流，而最直接有效的方式就是面对面沟通。

2、具备一定的业务和代码能力。QA需要对整个系统以及业务足够熟悉，这样才能从QA的视角帮助业务分析师和团队发现业务不合理或者缺失的部分。QA还需要有一定的代码能力，愿意听开发人员讲解他们的逻辑和实现，并通过提问题了解他们的思路，至少了解他们编写的测试代码。因为在验收阶段，QA会通过审查开发人员的自动化测试是否合理和全面，来帮助团队建立对自动化的信心。

3、管理工作的优先级。敏捷开发中团队每个成员都会从事质量保证的工作，也就是说质量保证的工作会有很多，所以每个人都需要承担。而团队中的QA角色需要确保所有的质量保证工作都能够有效执行。很多时候我们怎么保证工作有效执行呢？一种有效的方法是自己做。如果这样的话，QA就会回到过去QC的工作方式，会死的很惨而且效果不好。怎么避免这种结局？QA需要管理好工作的优先级，重要的事情先做，不重要的事情不要做。在这里有一点提醒大家，特别是新转行做敏捷QA的同学，在管理工作优先级的时候，不要去考虑事情是否紧急，一定要去考虑事情是否重要。在敏捷开发团队中，QA只能做重要的事情，不能做紧急的事情。紧急的事情谁做？由团队其他人来做。

4、抗压能力。在敏捷开发过程中，要求每个人都要参与质量保证工作。但是实际上，并不是每个人都知道怎么去做好质量保证工作的。这时，因为团队中有一个专门的QA角色，大家就会给这个角色过大的压力。这个时候需要QA具备一定的抗压能力，能够顶住压力，做好自己的工作，为团队服务，团结大家一起做好软件产品的质量保证工作。

具备了这四个特质，有助于在敏捷开发团队中担任好QA角色。过去做QC工作时，我们知道在什么阶段去做什么事情，那么在做QA工作时，每个阶段需要做什么呢？我们结合Sprint来看一看。

在用户故事分析时，QA需要参与到需求的分析工作，对用户故事进行审查，编写用户故事的验收用例。在迭代计划会中，QA需要主导自动化测试策略，确保自动化测试工作被识别并排入迭代计划。在Sprint开发过程中，QA需要跟每个开发人员保持沟通，确保测试工作有效执行，并且参与到代码评审过程中，审查自动化测试代码。在用户故事开发完成后，QA需要立即参与到用户故事的验收测试中，确认用户故事是否完成，还可以做一些探索性测试，以探索一些需求分析和设计时未考虑到的地方。在迭代演示环节，一般由QA来进行讲解和演示。在整个过程中，QA需要跟开发人员、业务分析师、客户进行交流，工作内容会涉及到多个迭代。QA与他们进行交流时，通常采用结对工作的方式进行：

QA 与业务分析人员结对：通常在业务分析师分析用户故事的时候，QA 要与业务分析人员结对编写验收用例。通过与业务分析人员结对，QA 能够更好的理解领域知识，从而有利于定义合适的测试用例；QA 从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。

QA 与开发人员结对：QA 和开发人员分别能给团队带来不同的技能集，认识到这一点很重要。作为一个团队，最好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。通常在实现测试自动化的时候，QA 与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高，有测试意识较强的 QA 参与能够保证自动化测试测得是真正需要测试的部分，而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。另一方面，QA 通过与开发人员结对，编码能力也会相应有所提高，而开发人员通过与 QA 结对，测试意识也会增强，更有利于编写质量较高的产品代码，更有利于形成全功能团队。

QA 与客户结对：客户是业务领域专家，通过与客户结对，QA 能够更好的从终端用户的角度理解系统，从而定义或者增加更多的端到端的测试用例；一旦 QA 理解了领域知识和终端用户的观点，其业务价值分析能力会有所提高，在团队需要的时候可以承担业务分析角色；在用户验收测试（UAT）阶段，QA 通过与客户结对，帮助客户熟悉使用系统，在必要时可以帮助客户解决一些系统问题。

要做好敏捷开发工作，质量管理方面需要从QC到QA进行转变。在转变过程中，测试工程师作为质量工作中的重要角色，需要带头完成转变，成为质量管理的先行者和领导者。