教学质量保证 (QA) 方法

软件测试 学习 技术
2022-01-21 17:05:17

我正在尝试向我的团队传授质量保证的来龙去脉，但在将“质量保证”提炼为其基本要素时遇到了一些挑战。

我有多年的经验，涵盖开发、质量保证、图形艺术、工程、现在的业务和营销等所有领域，现在有一个 10 人以下的小团队，他们都是初级（不到 1 年的实际生产经验）开发人员。

我正在寻找一些资源，将 QA 流程分解为他们可以快速适应和学习的东西，最终随着时间的推移建立一套技能。就我自己而言，我来自自学开发的时代，并且通过在大型出版商环境中工作多年，学到了我对 QA 的大部分理解。我假设这是我的教学技术（可能）或方法在让团队理解为什么 QA 很重要以及它如何适应开发方面存在不足。它们现在是可行的，但还没有真正“点击”这个过程，而且现在报告的错误质量也很缺乏。

诀窍是如何将其中的一些传递给我的团队，以便他们首先获得要点。

任何机会有人在这里：

  • 可以向我指出任何可以了解 QA 基础知识的在线资源吗？
  • 可以指出错误报告中最佳实践的简短列表吗？
  • 其他可能对以 QA 思维方式入职/教授团队有用的资源？
  • 也许将我与可以帮助清除这些内容的人联系起来？

任何帮助是极大的赞赏！

4个回答

我强烈建议您考虑为您的团队报名参加软件测试协会的优秀 BBST 系列。这是对他们理解我们为什么要测试所需的基本概念的一个很好的介绍，但也将挑战他们提高解释和分析他们关于测试的想法的技能，并让他们与来自世界各地的各种测试人员进行讨论在各种不同的环境中工作。该课程基于以下链接中的材料（可免费获得），但在实践练习、导师和同伴反馈方面包含更多内容，因此在时间和金钱上的（少量）投资是非常值得的。我的团队注册了我们的（当时）初级开发人员和测试人员，他们都喜欢这门课程并学到了很多东西。

如果你觉得你想要一些更快的东西，那么我建议你查看http://www.testingeducation.org/BBST/上的优秀资源- 并从你认为与你的团队最相关的资源中选择一个子集.

从Foundations开始，第2 课和第 5 课的视频现在听起来很相关。还有 Bug Advocacy 课程，但由于那里有很多材料，您可能只想选择第 6 讲（编写更好的错误报告）作为开始 - 它通过一个方便的助记符 (RIMGEA)，这是一组很好的步骤适用于您的错误。

我有时使用的缩略图定义是“单元测试和良好的开发实践确保它构建正确。QA/Test 还试图确保我们构建正确的‘它’”——也就是说，测试人员的重点往往是基础更广泛，并着眼于假定的最终用户。

我推荐的一些资源在这里很活跃：Joe Strazzere ( All Things Quality )、Alan Page ( Tooth of the Weasel )。软件测试俱乐部和SQA 论坛也有这些人。

您可能还想提出其他几点：

  • 测试人员的心态通常不同于开发人员的心态。开发人员专注于根据给定的规则（需求、用户故事等）构建一些东西。测试人员查看这些规则并询问“如果我违反它们会发生什么？”。
  • 测试/QA 并不是要成为看门人（“您的代码不得通过！”）。这是关于向团队的其他成员提供有关该软件的有价值的信息。
  • 除了最基本的东西之外，没有任何东西可以被完全测试。大多数操作系统中的内置计算器就是一个很好的例子。根本不可能检查所有四个基本函数是否一直有效（如果您的团队还没有接触过组合数学，这是一个开始它们的好地方 - 只是为了完全测试您正在谈论的两个个位数的加法100 次（我认为）测试。加上三个个位数，就是 1000 次测试。依此类推……这就是为什么测试的黑魔法是找出边界在哪里并在这些边界上进行测试（以及为什么测试人员是破坏者- of-rules - 每个规则都是一个边界）。
  • 没有任何软件可以在没有错误的情况下上线。曾经。因为没有什么可以被完全测试，所以事情会被遗漏。测试和编码一起工作，以防止最糟糕的产品退出生产 - 主要是。

随着时间的推移，可以提高团队错误报告的质量。您可能想突出报告的最佳报告并指出它们为什么好的原因 - 并使用好的错误和好的报告来做到这一点（我相信您知道，两者不一定相同） .

我不太喜欢严格的格式或最佳实践（我在这里的大部分答案都以“这取决于...”开头），但错误报告的一些好的指导方针是基于 What/Where/When/How 模式：

  • 什么- 描述错误的行为与测试人员预期发生的情况
  • Where - 系统中发生问题的位置（即环境）。它仅与一种配置有关，还是跨多种配置发生。它是浏览器还是操作系统特定的？
  • 何时- 如果可能，请给出问题开始发生的时间。
  • How - 你如何做到这一点？测试人员是否可以强制它每次都发生，或者它是那些烦人的间歇性事情之一？
  • 可选地，谁- 如果模块 X 中正在发生积极的开发并且模块 X 中出现问题，那么该开发可能是“谁”破坏了它。这不是要归咎于责备——而是要发现意想不到的后果。

质量保证意味着确保客户在开发产品时实现所有质量属性。既然您手下有一个团队，并且该团队将接受 QA 培训，那么全面的系统/领域知识将非常有助于找出实际和预期的行为。

试图找出什么不起作用对 QA 人员来说比相信一切都正常工作更有帮助。

您可以使用 JIRA（错误归档工具）正确归档错误。在提交错误时，应尽可能明确指定以下组件：

问题（错误）组件

  • 摘要（简短的一句话说明到底出了什么问题）
  • 优先级（将优先级从P0（严重）分配到 P5（低影响））
  • 修复版本（提交代码的提交 ID，如果有的话）
  • 环境（暂存/生产）
  • 描述（重现问题的逐步描述）

以下内容很有帮助，应酌情包括在内：

  • 屏幕截图（连同有效名称）
  • 屏幕录像（使用CamStudio、ALLCapture等工具）
  • 网络活动日志（来自网络面板的日志，即Firebug）

您也可以参考以下链接了解详细说明： http: //www.chiark.greenend.org.uk/~sgtatham/bugs.html

如果团队希望在 QA 方面更有效率，那么与开发人员进行的每日/每周站立会议/scrum 将会有很大帮助。在站立会议中，讨论高优先级问题将有助于开发人员跟踪要修复的重要内容。

解决问题后，QA 应重新测试这些问题，以验证它们不再可重现。

这里有一组测试思维导图，它们对于交流想法和测试时要考虑的事情非常有用 - http://www.ministryoftesting.com/resources/

其它你可能感兴趣的问题
上一篇程序员应该运行 QA 编写的自动化测试吗？ 下一篇类似于 Google Test 的 C++ 单元测试工具？