如何快速提供质量保证

将质量保证转变为质量协助

Laura Daly Laura Daly
浏览主题

传统的测试方法很难适应敏捷开发文化,团队被迫在产品质量和交付速度之间做出取舍。

为了解决这些问题,Atlassian 团队率先开创了一种名为“质量协助”的敏捷开发测试方法。根据这种方法,我们不是单独组建一个负责质量的测试团队,而是由质量协助工程师组成一个小团队,负责在整个开发团队中宣传和指导可持续的测试方法。详细了解这一转变及其实施方法:

  • 打造质量文化
  • 将测试职责重新交给开发人员
  • 预防缺陷,而不是检测缺陷

问答

阅读本演示文稿中的“问答”部分,详细了解由 65 名工程师组成的团队如何在只有 6 名质量协助 (QA) 工程师的情况下构建并快速交付高质量的产品。

问:开发人员需要多长时间才能接受这种思想?

答:改变整个团队的文化比改变个人更难。我们花了五年时间才让 Jira Software 团队达到如今的质量思维水平,但新的开发人员无需很长时间就能接受这一思想。他们会从同事(也就是现有开发人员)那里快速学习这种思想,通过搭档合作和研讨会快速掌握测试技能。其中最难的部分是掌握风险和产品的所有相关知识,这可能需要数年时间,但我们通过在 QA 启动和 QA 演示中进行知识共享可有效解决这一问题。

问:是否还需要测试用例,还是只有回归/自动化测试才需要测试用例?

答:我们的策略完全不涉及脚本化的手动测试用例。如果测试是指用一组预定义的步骤和一个定义的断言来执行“检查”,我们发现由计算机执行测试会比人工更为有效且不易出错。如果测试是指真正的测试,也就是需要批判性思维、调查自由和风险评估,我们发现最好将其作为探索性测试的一部分执行,以便将这种自由和智慧融入测试中。

问:开发人员的成本通常要高于测试人员。如果安排开发人员担任测试人员,是否会导致预算/人力的低效利用?

答:安排开发人员担任测试人员来执行独立的测试步骤确实会抬高成本,同时浪费开发人员的有效工作时间。但是,即使由测试人员执行一个独立的测试步骤,也完全是一件成本高昂又浪费开发人员时间的事情。每次测试人员将故事或缺陷推回给开发人员,不仅会产生测试成本,还会产生开发人员成本。通过将拒绝率从 100% 降低到 4%,我们节省了很多时间,这些时间过去都浪费在了发布之前重新编写故事和修复愚蠢的缺陷上。无论是调查、报告、筛选、评估、重现,还是修复内部发现的缺陷,我们都能在这些环节节省时间。此外,开发人员会从一开始就设计更易于测试的代码,因为他们知道自己后续便是测试的实际执行者。DoTing(开发人员执行测试)阶段是我们将质量向上游推动过程中的一个中间步骤,因此就能完全省略单独的测试步骤。这是一个可以获得不菲回报的短期投资。

问:我们的开发人员和 QA 测试人员位于不同时区。这个模式是否只适合同一时区?如何与远程团队开展协作?

答:我们位于波兰和越南的团队与位于澳大利亚的 QA 工程师一起实现了远程质量协助。远程工作的效果不如熟练的 QA 人员在现场进行参与,因为优秀质量协助工程师的主要职责之一就是与开发人员建立个人联系。而远程 QA 工程师常常难以掌握现场情况,也更难把握团队的整体文化。但是,我们能够通过视频电话成功进行远程 QA 演示、QA 启动和碰头会议,方法就是从开发人员的电脑直接呼叫 QA 人员的电脑,然后共享屏幕。

问:按故事构建 QA 注释,还是构建 QA 注释的知识库?如何应对重复出现的风险?

答:QA 注释按故事构建,因此通常都是 QA 工程师发现重复出现的风险模式。这几年来,随着我们 Jira Software QA 团队的发展壮大,这变得更加困难,因为每个 QA 工程师不一定知道别人所知道的事情。到目前为止,我们通过两种方式来缓解这种情况:一是每周召开知识共享会议;二是建立维基页面,并在这些页面中跟踪常见或意外风险。目前情况已经得到控制,没有再出现更多问题。眼下,我们正在建立一个更为结构化的知识库,其中包含针对每次提交运行的规则数据库。例如,如果发现 Jira Software 代码中使用了“User”对象,则会在事务中添加一条评论:“如果当前用户匿名,则 User 对象可能为 null,请确保已正确处理此问题”。这将有助于我们从 QA 人员那里获取知识,最理想的情况下甚至可以取代 QA 演示和启动。这将对我们大有裨益!