小型开发团队的质量保证

Kim*_*m L 29 qa

理想情况下,在项目中,开发人员,测试人员,QA经理等都会对代码质量做出贡献.但是,如果你没有那种资源怎么办?例如,如果您只有三名开发人员并且没有资源聘请全职QA经理,您如何确保代码质量符合设定标准?

您在质量保证方面注意什么样的事情?质量不仅仅是代码执行它应该做的事情(代码通过自动测试正确测试).质量也与代码清晰(可读,可维护,结构良好,文档记录等)有关.

我期待听到您为团队应用了哪些流程,以确保质量符合既定标准.我们已经应用了一个流程,我们在开发人员之间轮换QA角色.每个开发人员一次负责一周的QA.修改每个变更集并检查现有测试是否通过,是否已编写新测试,代码是否干净,当然还有项目构建.

编辑:

当然,这个过程中的一些可以通过CI自动化,但我正在寻找的是人为因素的经验.我的意思是,你如何确保每个开发人员编写干净的代码并实际测试所有内容.除非您手动检查,否则测试覆盖范围不会告诉您是否所有内容都已经过测试(从自动角度来看,实际上不可能实现100%覆盖率).即使覆盖范围会告诉您某些内容已经过测试,但这并不意味着实际的测试会测试正确的内容.

sti*_*k81 16

您是否使用任何软件开发方法,例如Scrum?Scrum是一种很好的敏捷工作方式,但也有其他好的流程.

我们使用Scrum.这是使我们的团队高效的好方法,但它也是一种向我们开发软件的方式引入规则的好方法.像你一样 - 我是一个小团队的一员.不幸的是,我们没有得到QA部门或任何专门的QA人员的祝福.在Sprint期间完成的工作应该是可以发布的,因此团队中的开发人员需要处理QA工作.

在Scrum和Kanban中,您使用任务板来跟踪当前的Sprint,这些板通常有一列用于等待QA批准的任务.我们所做的是,当任务完成后,我们将其移至"准备验证".然后团队中的另一位开发人员执行QA工作.他会的:

  • 确保新功能执行预期的操作/错误已修复/等.
  • 验证是否有足够的单元测试
  • 快速进行代码检查以检查代码是否干净且易于理解

如果审核中有不满意的内容,他会将任务重新启动,并且需要先修复它才能进入另一个QA会话.

我们都没有真正了解QA,但在引入验证后我们的代码质量有了提升.


ndp*_*ndp 12

听起来你正在做很多正确的事并提出正确的问题.

在过去的三年里,我一直在2-4人的开发团队工作,没有任何正式的质量保证.我们有非常满意的客户和低虫数.

这对我们有用,因为:

  • 每个人的首要任务是优质软件.我们不会传递QA角色,但所有人都会这样做.我们希望我们的代码看起来很好.所有开发人员都渴望编写单元测试和集成测试,并且团队面临着确保测试存在的压力.
  • 广泛配对节目.这种小开销显着提高了质量,并具有各种优点.您的发展是对"质量"意味着什么的共同理解,并自己回答问题.
  • 我们定期进行"回顾",询问我们可以改进的内容.与此相关的是,如果我们遇到质量问题,团队会找出需要改变的内容来解决这个问题(5 Whys分析).为了解决问题,我们制定了"双眼检查"等规则.

总而言之,质量最终是关于满意的用户.在抽象讨论质量(并争论变量名称)时,我试图让人们回到这一点.最终它应该是关于软件如何解决用户问题,而不是崩溃只是第一步.


Tim*_*sch 8

首先,如果您还没有这样做,我强烈建议您设置一个也运行单元测试的自动构建,最好使用代码覆盖来检查是否存在需要更多单元测试覆盖的区域.我不是要求100%代码覆盖率的忠实粉丝,但只有大约60%-80%的东西可能需要调查.

我曾在手工完成日常构建的团队中工作,而构建构建的开发人员也必须执行集成工作,因为签入条件常常是"它构建在我的机器上".获得自动构建,每次签到或至少每小时一次,并要求签入打破构建的开发人员修复它是朝着正确方向迈出的重要一步,并且(希望)确保随着时间的推移提高质量.

代码清洁是我发现很难从外部给团队留下深刻印象的东西.从某种意义上说,这听起来你在做什么 - QA角色清理代码? - 但也许我弄错了.如果我没有弄错,我想你需要改变它.质量不是你能够或应该在事后想到的事情,致力于代码的人应该努力实现质量目标,代码审查应该突出原始开发人员需要改进代码的领域,但没有"QA"人"进来清理它.道歉,如果我有误解,但如果这是你的过程,这需要改变的一部分,现在因为你做妈妈的清理杂乱的青少年的卧室相当.


Chr*_*ber 6

在一个小团队中,最重要的是选择你能找到的最好的人,并且不惜一切代价避免任何破坏你的开发团队的人.如果你已经有这样的人,请摆脱它们.

我发现以下所有内容对于保持质量有用,无论是否有人担任官方QA角色:

  • 自动化单元测试
  • 自动构建 - 尽可能频繁地管理
  • 测试的覆盖率测量
  • 签证的同行代码审查
  • 接受的编码约定和标准
  • 个人分支
  • 经常合并
  • 吃自己的狗粮!

其中,自动化测试是最重要的,其次是同行评审.我没有发现组代码演练值得花费时间,但是在办理登机手续之前或之后的一对一评论通常是值得的.如果签入保持相对较小并且不会结合许多不相关的更改,则签入审核最有效.

个人分支允许开发人员在不准备合并的情况下进行多次签入而不影响其他开发人员的工作,但经常合并以避免来自未经测试的分支的未被注意的问题.