如何设置QA部门？

Question

我是一个小团队的资深成员(另外两个程序员)。我们都是公司的新人，我一直在设置所有的开发基础设施。到目前为止，我有一个很好的版本控制系统(Git)，一个很好的问题跟踪系统(Redmine)，并且我即将建立一个构建环境(Hudson)。我现在正在考虑设立我们的QA部门。我想建立一个敏捷的开发过程，比如Scrum，但这还不起作用。那么，如何开始解决QA问题呢？开发测试计划、遵循计划、报告结果的好过程是什么？是否有组织和运行QA的工具？

谢谢!

Answer 1

你表明你想要一个QA组/部门，但是你没有说为什么。关于QA团队的工作，有很多假设。

QA的基本性质是确保在第一时间构建正确的产品。Software Quality Assurance通常专注于开发代码的过程。

或者，您只是在寻找其他人来为您测试代码吗？

如果您的重点是QA的测试方面，我将尽可能多地推动您团队的开发部分。自动化测试将在很大程度上帮助提高首次获得正确测试的机会。此外，测试极大地降低了产品内部更改的风险。而且，不要将大部分测试编写转移到团队的一个子集上。您希望将可测试性作为设计的一个关键方面，而开发人员如果没有编写足够的测试，就不要在他们的设计中充分考虑它。指望一个人或一组人来运行一系列测试意味着您不能经常运行它们，并且您会倾向于低估较旧的回归测试。

如果您的重点是QA，而不仅仅是测试，那么值得指派一个人，他的主要角色是查看产品、其复杂性、度量标准和测试覆盖率，以确定在代码库中的正确位置是否有足够的测试。这个角色与监控整体设计的架构师或专门从事可用性和/或设计指导用户界面开发的人没有什么不同。角色应该是拥护正确的工作，而不一定是实现工作。

我个人对以上所有问题的一个例外是至少需要一个具有正确心态的人来执行exploratory testing。探索性测试应该是上述所有测试的子集。而且，当发现问题时，应该用来反馈给自动化测试(例如，如果发现了错误，修复行为的一部分应该是编写证明错误和修复的测试。而且，如果代码复杂性的测试覆盖率较低，请编写其他几个测试，以确保没有额外的bug)。尤其是UI，需要探索性测试。探索性测试通常很好地解决了完成任务的可用方法的组合，以及在较旧的UI框架中自动化测试的困难。

更新:你可能想看看Episode 164: Agile Testing with Lisa Crispin

Answer 2

如果你使用Scrum，我想你指的是所有敏捷方法。测试计划、bug报告和诸如此类的东西会不会有一些开销？

至于工具，我建议添加wiki或jira作为存储任务、相关用户故事和相关bug的位置。

至于设立QA部门(一人为部门O.o )，我建议去掉QA部门。标签，只需再雇用一个专注于测试的团队成员即可。你可能需要在敏捷领域工作过并且有测试经验的人。如果那个人知道探索性测试(工具和技术)，那就好了。

如果您考虑测试自动化(因为您已经有了Hudson)，那么测试人员将需要具备一些编程技能。另一方面，你可以把自动化留给开发人员，专注于获得好的测试人员，而不是能做一些代码的普通测试人员。无论如何，我会实现一些测试自动化，一些回归。

首先，不要陷入QA/流程/测试计划/文档繁重/详细的手动脚本/面向流程的事情。保持它的灵活性，否则你很快就会注意到它并不能真正工作。

=================edit将解决Jacko comment============================的问题

因此，我假设，不打算为这个开源项目做出贡献，而是制作一些插件，既使用它的代码，又扩展它的功能，这样它就可以满足您在自己的项目中的需要？凉爽的。

因此，您需要：

1)对方开发的开源项目，有自己的进度、项目计划等

2)您开发的扩展/插件，使您可以使用该项目

3)你自己的项目，有一些功能通过插件委托给开源项目。

我猜所有这些都是通过某种消息传递机制在代码级集成的。在这种情况下，我会说，你需要一个会写代码的人，不管他的背景如何(虽然开发人员会更容易找到，但他会对编写自动化测试感兴趣吗？)。

无论如何，你需要自动化测试：

A)显然你的项目--像你现在这样写单元测试，或者更多一点。

B)单元测试，它将确保主项目中的任何更改都不会中断其与插件/扩展的交互(用于开源项目)

C)插件/扩展的单元测试--这是你自己写的代码，所以你需要单元测试，因为你的项目需要A

D) (不是很明显的部分)你需要测试来看看开源项目中的变化是否会影响你的插件。

当然，作为C和D的A和B会以某种方式重叠，但从形式上讲，这是您需要注意的。

所以，回到最初的问题，我认为你不需要QA部门(顺便说一句，scrum不是说要去掉部门标签，只有一个团队吗？)在传统意义上。找一个能够(并且喜欢)创建自动化测试的人，可能是在单元测试级别。使用Scrum。有一个团队。跳过全面的文档，正式的流程，ISO/IEEE标准的测试。创建轻量级文档，只是为了有主要/一般目标/方法/假设可供参考。

...and如果它不起作用，在回顾上讨论它，试着调整东西，尝试新的东西。持续改进！