左手测试，右手QA

左手测试，右手QA

在我们的团队中，QA角色身兼两职：测试和过程改进。以往我们对新进来的员工的期望值是先承担测试任务，在能较好地完成测试任务之后，才考虑让他参与一些SQA的工作。因此，有些已经进来大半年的同事，感觉对SQA还是没有什么概念，更没有机会去实践。或者有的同事想参与一些SQA的工作，却感到没有头绪，不知如何下手。而实际工作中我发现，QA的能力可以在每日工作中从点滴、从最开始就培养，这个与以往有没有SQA的知识和经验没有关系。因为简而言之，QA的工作主要围绕持续改进展开。而无论你是否有经验，每天的工作中你都在以自己独特的视角看问题，并可能看到改进的空间。那么，测试人员如何在日常工作中去逐步培养自己的QA能力呢？

 

1.找到问题

 

感受到一个问题，有时是出于关怀，你发现有人/自己正因为某件事情而痛苦；有时是出于怀疑，你发现有件事情和你想象/预计的不一样；还可能是出于直觉。但感受到问题其实并不是一件容易的事情。

 

如果感受不到问题，我们可以试图通过多种方法积极寻找。

 

如果你刚到一个项目组,提不出问题，可以先去听听别人（项目组成员、用户等等）的抱怨，或者想想自己痛苦的地方（比如找不到文档，系统操作不直观学习起来困难等等），这些就可能是问题。另外，为了培养自己找问题的习惯，可以给自己一个定量目标，每周去总结一个“疑似问题”。经过实践，这个带点自我强迫的方法对于找问题很有帮助。比如，虽然你的测试用例经过了和开发人员的评审，但是测试时你却发现几个重要的分支或者逻辑还是在代码中忘记实现了。除了报告缺陷，是否还有什么有共性的问题存在，并值得改进呢？

 

如果你在一个项目组大家合作得不错，似乎没有什么问题，但一个看 似不错的结果其实可能隐藏了问题。比如，完成工作，交付高质量的软件产品可以通过多种渠道实现，而非一定体现了高质量。可能是牺牲了时间进行好几轮的测试 和修复和全面的回归测试，又或者某一块有一个英雄人物能够以一己之力确保这块没有问题。又如，虽然大规模代码重构的时候，内部测试能找到大部分重要的缺 陷，但是否测试人员心理还是很抗拒和没底的？虽然这些问题不是单靠测试人员就能改善或者达到，但找到影响质量的问题确实需要测试人员的独立视角和贡献。如 果一个测试人员、一个测试团队能够跳开测试的圈圈，从更广阔的角度看到影响质量的其他环节，帮助开发人员克服一些老的制约生产力和质量的毛病或者习惯，从而提高开发团队的水平，而更高开发水平的开发团队又对测试团队会提出更高的要求，那么这样的良性互动是我们都想看到的。现在被大家所广泛追捧的敏捷开发就提倡忽略角色的分工，大家一起为质量贡献自己的一份力量。

 

前面说的是流程方面的问题，其实即使是被测程序的问题也存在于在整个软件开发周期。虽然传统对测试的理解是测试找问题更多集中在执行阶段，但借用QA的预防为主的思路，程序的问题也可以通过对需求和设计的评审及时发现和纠正，避免后期更大的浪费。

 

2.探究问题

 

感 受到问题之后，需要一种探寻真相的精神去一探究竟。很多人能感受到问题，但是很遗憾地是当有更具体的任务在手头的时候，往往就忽略了这个问题。或者知道问 题很大，也知道有各种原因的阻碍，因此采取放任自流的态度。这里要介绍一个好的习惯，就是把你当前没有时间去细想的问题先记录下来，以后再找机会去跟踪执行。类似outlook的任务或者一些桌面电子便签等工具可以帮助你设定任务及提醒执行。除了记录，还有一个好习惯就是去外部寻找一些同行的交流。如果看到同样/类似的话题，相信会驱使你有更大的兴趣去看自己碰到的问题，也启发你从不同角度看问题。

 

QA的工作更多的针对的是有共性的问题，所以对这类问题的探究往往需要多个样本。换言之，在报告每一个缺陷的时候我们是在做测试，而对测试结果进行总结、归类、抽象出背后共性的问题则向QA靠近了一步。

 

 

3.判断问题

 

3.1判断一个问题是否真的是问题

测 试人员通常看到实际执行结果后就能马上判断出其与预期结果之间的差异，从而判断是否存在问题。但过程改进相关的问题就没有那么一目了然了。比如，我们收到 一个来自生产环境的缺陷，是因为一个需求变更的影响点大家都没有想到，直到生产环境暴露出来。开会的时候有人提出我们的开发流程不完善，如果能够建立起需 求、设计和测试用例的跟踪矩阵，那么在做影响分析的时候就能顺藤摸瓜，避免此类问题了。听起来不错，是么？可是，如果我们细想，这种类似问题在生产环境对 用户的影响大么？可以绕过去么？此类问题出现的次数多么？如果我们建立这个跟踪矩阵，维护代价有多高？前提还是我们首先要想到所有的内在联系（而这个本身 就是无法确保的）。两相权衡，“没有这个跟踪矩阵”是我们现在的问题么？

 

“判断一个问题是否真的是问题”最好能广泛听取不同的意见，并找到根源。

 

3.2判断一个问题是否需要被马上解决

“判断问题是否需要马上解决”在某种程度上这有点象测试人员去设定缺陷的优先级。虽然所有被发现的缺陷都被记录，但是当前版本需要修复的或者可能只是其中一部分，而这一部分中还有需要尽快修复的和可以稍后修复的差别。过程改进的问题也是一样，有个主次和优先级之分。

 

4.解决问题

 

对于确实是问题的，我们应该去积极地寻找解决方案。但是新到一个公司或者项目组，发现了问题之后，不要急着去提出自己的解决方案，而应该先试图了解它的来龙去脉和曾经进行过的改进尝试，以及执行中实际的一些阻碍。

 

解决问题通常牵涉到开发团队中各个角色，除了明确负责的一方，还要对参与的其他方也进行充分的沟通。

 

确认开始执行之后，为了确保执行的正确性和力度，一定要跟踪执行。一个没有跟踪执行的方案如同瞎子射箭。这样的话，无论射多少回，都是没有目的性和方向性的，也无法在以前的基础上持续改进的。质量理论中常提到的PDCA循环讲的也是这个道理。

在解决问题方面，有很多和测试、质量无关，但和思维、管理类相关的书和文章。例如：《第五项修炼》中就提出对解决问题很有帮助的五大方面：系统思考、自我超越、心智模式、建立共同愿景、团队学习。《金字塔原理》中提出的界定问题、结构化思考、演绎与归纳等多种模式也能帮助我们剥茧抽丝，抓到问题的本质和可行的方案。

 

6.QA能力进阶

从上面我们看到，QA能力的培养贯穿于每日工作的点滴。其进阶可以大致分为以下级别。

 

(1)发现的问题级别:

       初级:问题已经发生,而且大家都感受到了(项目组中大家都觉得有问题的问题)

       中级:问题已经发生,但只有少量人感受到了(问题已经发生,但是其危害还没有扩散)

       高级:问题还没有发生,很多人没有意识到(一个解决方案在不同的实施环境中会有的问题)

 

(2)解决问题的能力的级别：

       初级：可以提出方案，但不能提出很合理的、可以实施的方案

       中级：可以提出合理的可以实施的方案，但是实施效果不太好（方案中存在着一些重要的影响执行的因素没有考虑到）

       高级：可以提出合理的方案，且实施效果好，整个团队受益

 

其实，有时想想除了 QA更需要有丰富的思路去提出可能的解决方案之外，测试人员和QA人员对技能的要求有很多相通之处：都需要有敏锐的触角去发现潜在的问题，有执著的勇气去验证和报告预期与实际结果之间的差异，有务实的精神去跟踪和督促执行。所以，让我们 左手测试，右手 QA，互相促进， 帮助质量改进更上一层楼！