如何设置QA部门？

Question

我是一个小团队的高级成员（另外两名程序员）。我们都是新来的公司，我一直在设立所有的开发基础设施。到目前为止，我拥有一个出色的版本控制系统（Git），一个出色的问题跟踪系统（Redmine），而且我即将建立一个构建环境（Hudson）。我现在正在考虑设立我们的质量保证部门。我想建立一个像Scrum这样的敏捷开发流程，但这还没有起作用。那么，我如何开始质量保证问题呢？遵循计划和报告结果，开发测试计划的好过程是什么？是否有任何组织和运行QA的工具？

谢谢！

Answer 1

你表示你想要一个QA小组/部门，但你不知道为什么。关于质量保证小组的工作有很多假设。

QA的基本性质是为了确保正确的产品是第一次构建正确。 Software Quality Assurance通常是关注开发代码的过程。

或者，你只是在寻找别人来测试你的代码吗？

如果您的注意力集中在质量保证的测试方面，我会尽可能地推入您的小组的开发部分。自动化测试将有助于提高第一次获得正确的机会。此外，测试显着降低了产品内部变化的风险。而且，不要将大部分测试写作转移到团队的一个子集上。您希望将可测试性作为设计的关键方面，而开发人员不会编写足够多的测试，因此不要在设计中充分加以体现。指望一个人或一群人在一堆测试中跑步意味着你不能经常运行它们，而且你往往会低估旧的回归测试。

如果您的重点是QA而不仅仅是测试，那么值得分配一个主要角色的人是看产品，其复杂性，度量和测试覆盖率，以确定是否有足够的测试在正确的位置代码库。这个角色与监控总体设计的架构师或专门从事可用性和/或设计指导用户界面开发的人员无异。角色应该是支持正确的工作，而不一定要执行工作。

我个人对上述所有情况都有一个例外，那就是至少有一个人有正确的心态去执行exploratory testing。探索性测试应该是上述所有测试的一个子集。并且，当发现问题时，应该用于反馈到自动化测试中（例如，如果发现错误，则修复操作的一部分应该是编写测试来演示错误和修复。而且，如果测试覆盖范围是代码复杂度较低，编写其他几个测试以确保没有其他错误）。用户界面尤其需要探索性测试。探索性测试通常很好地满足了用于完成任务的可用方式的排列，以及在旧UI框架中自动化测试的困难。

更新：您可能想要退房Episode 164: Agile Testing with Lisa Crispin

Answer 2

如果你打算使用Scrum，我想你的意思是所有的敏捷方法。不会是测试计划，错误报告和类似的东西有点花销？

至于工具，我会建议添加wiki或jira作为地方存储任务，相关的用户故事和相关的错误。

至于设置QA部门（一个人为部门O.o），我建议放弃'QA部门'。标签，只需聘请一名专注于测试的团队成员。 您可能希望在敏捷工作并具有测试经验的人员。如果那个人知道探索性测试（工具&技术），那将是很好的。

如果您考虑测试自动化（因为您已经拥有Hudson），测试人员需要掌握编程技巧。另一方面，您可以让开发人员自动化，并专注于获得优秀的测试人员，而不是可以执行一些代码的平均测试人员。无论如何，我会实施一些测试自动化，一些回归。

有一件事，不要陷入质量保证/流程/测试计划/文档繁重/详细的手动脚本/流程导向的事情。保持敏捷，否则很快你会注意到它并不真正起作用。

=================编辑以解决Jacko评论======================== ====

因此，我假设，不打算为这个开源项目做出贡献，而是让一些插件使用它的代码，但也扩展了它的功能，所以它会适合你自己项目中的需求？凉。

所以，你必须：
其他方开发的，它有自己的时间表，项目计划等 1）开源项目
2）扩展/插件您开发，使该项目可为您
3）你自己的项目有一些通过插件委托给开源项目的功能。

我想所有这些都通过一些消息传递机制集成在代码级别上。在这种情况下，我会说，你需要一个可以编码的人，不管他的背景如何（尽管开发人员会更容易找到，但他会对编写自动化测试感兴趣吗？）。
无论如何，你需要自动化测试：
A）显然你的项目 - 写你现在做的单元测试，或者更多一点。 B）单元测试将确保你的主项目的任何变化都不会中断它与插件/扩展的交互（开源项目的那些变化）
C）插件/扩展的单元测试 - 它是你编写的代码，所以你需要进行单元测试，因为你的项目需要A
D）（不是很明显的部分）你需要测试以确定开源项目中的变化是否会影响你的插件。

当然A和B作为C和D会以某种方式重叠，但在形式上这就是你需要知道的。

因此，回到原来的问题，我不认为你需要质量保证部门（顺便说一句，不是说Scrum说放弃部门标签，并有一个团队？）在传统意义上。找一个能够（并且喜欢）创建自动化测试的人，可能在单元测试级别上。跟Scrum一起去吧。有一个团队。跳过全面的文档，正式的流程，ISO/IEEE标准进行测试。创建轻量级文档，只是为了提供主要/总体目标/方法/假设。
...如果它不起作用，回顾讨论它，尝试调整的东西，尝试新的东西。连续的提高！