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