我是一个小团队的高级成员（另外两名程序员）。我们都是公司的新手，我一直在设置所有的开发基础设施。到目前为止，我有一个出色的版本控制系统（Git），一个出色的问题跟踪系统（Redmine），我即将建立一个构建环境（Hudson）。我现在正在考虑建立我们的质量保证部门。我想建立一个像Scrum一样的敏捷开发流程，但这还没有成功。那么，我如何开始质量保证问题呢？根据计划，报告结果，制定测试计划的良好流程是什么？有没有用于组织和运行QA的工具？
谢谢！
答案 0 :(得分：6)
如果你要使用Scrum，我想你的意思是所有敏捷的方法。不会是测试计划，错误报告和类似开销的东西吗？
至于我建议添加wiki或jira作为存储任务，相关用户故事和相关错误的位置的工具。
关于设立QA部门（一个人作为部门O.o），我建议放弃'QA部门'。标签，只雇用一名专注于测试的团队成员。 您可能需要敏捷工作且具有测试经验的人员。如果那个人知道探索性测试（工具和技术）会很好。
如果您考虑测试自动化（因为您已经拥有Hudson），测试人员需要掌握一些编程技巧。另一方面，您可以将自动化留给开发人员，并专注于获得比可以执行某些代码的普通测试人员更好的测试人员。无论如何，我会实施一些测试自动化，一些回归。
有一件事，不要落入质量保证/流程/测试计划/文档重/详细的手动脚本/流程导向的事情。保持敏捷，否则你很快就会注意到它并没有真正起作用。
=================编辑以解决Jacko评论========================= ===
所以我假设，不打算为这个开源项目做出贡献，而是制作一些将使用其代码但又扩展其功能的插件，以便它适合您自己项目中的需求？凉。
所以你有：
1）由其他方开发的开源项目，具有自己的时间表，项目计划等
2）您开发的扩展/插件，使该项目可用于您
3）您自己的项目具有通过插件委托给开源项目的一些功能。
我想通过一些消息传递机制，所有这些都集成在代码级别上。在这种情况下，我会说，你需要一个可以编码的人，无论他的背景如何（虽然开发人员更容易找到，但他是否有兴趣编写自动化测试？）。
无论如何，你需要进行自动化测试：
A）显然你的项目 - 像现在一样编写单元测试，或者可能更多
B）单元测试，确保主项目中的任何更改不会破坏其与插件/扩展的交互（开源项目的交互）
C）插件/扩展的单元测试 - 这是您编写的代码，因此您需要进行单元测试，因为您需要为您的项目提供A
D）（不那么明显的部分）您需要测试以查看开源项目中的更改是否会影响您的插件。
当然A和B作为C和D会以某种方式重叠，但正式地说这是你需要注意的。
所以，回到原来的问题，我认为你不需要传统意义上的QA部门（顺便说一句，不是scrum说要放弃部门标签并拥有一个团队吗？）。找一个可以（并且喜欢）创建自动化测试的人，可能在单元测试级别上。跟Scrum一起去。有一个团队。跳过全面的文档，正式的流程，ISO / IEEE标准进行测试。创建轻量级文档，只需要参考主要/一般目标/方法/假设 ...如果它不起作用，请在回顾中讨论它，尝试调整一些东西，尝试新的东西。持续改进！
答案 1 :(得分：5)
您表示您想要一个QA小组/部门，但您没有说明原因。关于QA小组的工作有很多假设。
QA的基本性质是确保正确的产品是第一次正确构建。 Software Quality Assurance通常是关注开发代码的过程。
或者，您是否只是在寻找其他人为您测试代码？
如果您的重点是质量保证的测试方面，我会尽可能地推进您小组的开发部分。自动化测试将有助于提高第一次正确测试的机会。此外，测试显着降低了产品内部变化的风险。并且，不要将大部分测试写作转移到团队的一个子集上。您希望将可测试性作为您的设计的关键方面，并且开发人员没有编写足够的测试，在设计中不要充分加权。指望一群人或一组人经过一系列测试意味着你不能经常运行它们，你会倾向于不重视旧的回归测试。
如果您的重点是质量保证而不仅仅是测试，那么值得指定一个主要角色的人是查看产品，其复杂性，指标和测试覆盖率，以确定代码中是否有足够的测试位置基础。这个角色与监控整体设计的架构师或专注于指导用户界面开发的可用性和/或设计的人没有什么不同。这个角色应该是支持正确的工作，而不一定是为了实现这项工作。
我个人对上述所有情况的一个例外是至少需要一个具有正确心态的人才能执行exploratory testing。探索性测试应该是上述所有测试的子集。并且，当发现问题时，应该用于反馈到自动化测试中（例如，如果发现错误，修复行为的一部分应该是编写测试以证明错误和修复。并且，如果测试覆盖率是代码复杂度低，写几个其他测试，以确保没有其他错误）。特别是UI需要探索性测试。完成任务的可用方法的排列以及在较旧的UI框架中自动化测试的难度通常通过探索性测试得到很好的服务。