教学质量保证方法

Question

我正在尝试向我的团队传授质量保证的细节，但是我遇到了一些挑战，把"QA“提炼成它的基本元素。

我有多年的经验，涉及所有领域的开发，QA，图形艺术，工程，现在商业和营销，现在有一个10岁以下的小组，他们都是初级(不到1年的实际生产经验)的开发人员。

我正在寻找一些资源，这些资源可以将QA过程分解为一些他们可以快速适应和学习的东西，最终建立起一套技能。对我自己来说，我来自于自学发展的时代，并且从在大型出版商环境中工作多年中学到了我对QA的大部分理解。我假设是我的教学技巧(很可能)或方法不足以让团队理解QA为什么重要，以及它如何适应开发。它们现在是可行的，但还没有真正地“点击”这个过程，而且现在报告的bug的质量也很差。

诀窍是，如何把这些东西传递给我的球队，这样他们就能先得到突出的分数。

这里的人是否有可能：

• 能告诉我任何关于QA基础的在线资源吗？
• 能告诉我一份简短的错误报告最佳实践清单吗？
• 其他资源，可能有用的寄宿/教导团队与QA思维？
• 或者帮我找个能帮我把这些冲掉的人？

任何帮助都是非常感谢的！

Answer 1

我偶尔使用的一个缩略图定义是“单元测试和良好的开发实践--确保它构建正确。QA/Test也试图确保我们构建的是正确的'it'”--也就是说，测试人员的关注点往往更广泛，并且着眼于假定的最终用户。

我推荐的一些资源在这里是活跃的: Joe (万物质量)，Alan (黄鼠狼之牙)。还有软件测试俱乐部和SQA论坛的人。

你还想说几点：

• 测试人员的心态通常与开发人员的心态不同。开发人员专注于根据规则(需求、用户故事等等)来构建他们所得到的东西。测试人员看着这些规则并问：“如果我违反了这些规则，会发生什么？”
• 测试/QA并不是要成为看门人(“您的代码不能通过！”)。这是给团队其他成员关于软件的有价值的信息。
• 以上最基本的任何东西都不能完全测试。大多数操作系统中内置的计算器就是一个很好的例子。要检查所有四个基本函数是否一直有效是不可能的(如果您的团队还没有接触过组合数学，那么这是一个很好的开始--只是为了完全测试您所说的100 (我认为)测试中添加的两个个位数。要添加三个个位数，即1000个测试。等等..。这就是为什么测试的黑色艺术是确定边界在哪里，并在这些边界上进行测试(以及为什么测试人员是规则的违反者--每条规则都是边界)。
• 任何软件都不会没有错误而运行。永远不会。因为没有什么东西能被充分测试，事情就会被错过。测试和编码一起工作，以防止最坏的生产-大部分。

改进团队错误报告的质量是可以随着时间的推移而发生的事情。您可能希望突出报告中最好的部分，并指出它们为什么是好的--并且对好的bug和好的报告都这样做(我相信您知道，两者并不一定是相同的)。

我不太喜欢僵化的格式或最佳实践(这里的大多数答案都是以“它取决于.”开头的)，但是一些关于bug报告的好指南是基于什么/哪里/何时/如何模式的：

• 什么-描述错误的行为与测试人员期望发生的情况
• 哪里-在系统中哪里发生问题(即环境问题)。它是只与一种配置相关，还是跨多个配置发生。它是特定于浏览器还是操作系统？
• 如果可能的话，在问题开始发生的时候给出一些想法。
• 你是怎么让这一切发生的？测试人员能强迫它每次都发生吗?还是它是那些恼人的间歇性事情之一？
• 或者，如果在模块X中发生了积极的开发，而在模块X中发生了某些事情，那么这种开发很可能是“谁”破坏了它。这不是指责，而是发现意外的后果。

Answer 2

我强烈建议您考虑为您的团队注册软件测试协会的优秀BBST系列. --这是一个很好的介绍，介绍了他们需要了解为什么要进行测试的基本概念，但也会要求他们提高解释和分析测试想法的技能，并让他们与来自世界各地在各种不同环境下工作的测试人员进行讨论。该课程基于以下链接中的材料(免费提供)，但在实践练习、家教和同行反馈方面包含了更多的内容，因此值得在时间和金钱上进行(小规模)投资。我的团队注册了我们的初级开发人员和测试人员，他们都喜欢这门课程，也学到了很多东西。

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

从地基材料开始，第二课和第五课的视频现在听起来相当贴切。也有Bug倡导课程，但由于有很多材料，你可能只想选择第六堂课(写一个更好的bug报告)作为开始-它走过了一个方便的助记符(RIMGEA)，这是一套很好的步骤，应用到您的错误。

Answer 3

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

试图找出不起作用的东西对QA人员是有帮助的，而不是相信一切都很好。

您可以使用JIRA(bug归档工具)正确地归档bug。在提交错误时，应明确说明以下组件，如果可能的话：

问题(Bug)组件

• 摘要(短短的一行说明到底出了什么问题)
• 优先级(从P0(严重)到P5(低影响)指定优先级)
• 修正版本(如果有，则提交代码的提交ID )
• 环境(分期/生产)
• 描述(一步一步地描述问题的再现)

以下内容是有益的，应酌情包括在内：

• 屏幕截图(连同有效名称)
• 屏幕记录(使用CamStudio、ALLCapture等工具)
• Net活动日志(日志来自Net，即Firebug)

此外，您还可以参考以下链接以获得详细说明：http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

如果团队希望在QA方面更有效率，那么每天/每周与开发人员的对峙/scrum将会有很大的帮助。在这个过程中，讨论高优先级的问题将有助于开发人员跟踪需要解决的重要问题。

在重新解决这些问题后，应由QA重新进行测试，以验证它们不再可重复。