理想情况下，在项目中，开发人员，测试人员，QA经理等都会对代码质量做出贡献。但是，如果你没有那种资源怎么办？例如，如果您只有三名开发人员并且没有资源聘请全职QA经理，您如何确保代码质量符合既定标准？
您在质量保证方面有哪些注意事项？质量不仅仅是代码执行它应该做的事情（代码通过自动测试正确测试）。质量也与代码清晰（可读，可维护，结构良好，文档记录等）有关。
我期待听到您为团队应用了哪些流程，以确保质量符合既定标准。我们已经应用了一个流程，我们在开发人员之间轮换QA角色。每个开发人员一次负责一周的QA。修改每个变更集并检查现有测试是否通过，是否已编写新测试，代码是否干净，当然还有项目构建。
编辑：
当然，这个过程中的一部分可以通过CI实现自动化，但我正在寻找的是人为因素的体验。我的意思是，你如何确保每个开发人员编写干净的代码并实际测试所有内容。除非您手动检查，否则测试覆盖范围不会告诉您是否所有内容都已经过测试（从自动角度来看，实际上不可能实现100％覆盖率）。即使覆盖范围会告诉您某些内容已经过测试，但这并不意味着实际测试会测试正确的内容。
答案 0 :(得分：16)
您是否使用任何软件开发方法，例如Scrum？ Scrum是一种很好的Agile工作方式，但也有其他好的流程。
我们使用Scrum。这是使我们的团队高效的好方法，但它也是我们开发软件的方式引入规则的好方法。像你一样 - 我是一个小团队的一员。不幸的是，我们没有幸运的QA部门或任何专门的QA人员。在Sprint期间完成的工作应该是可以发布的，因此团队中的开发人员需要处理QA工作。
在Scrum中，例如看板您使用Task Board来跟踪当前的Sprint，这些板通常有一列用于等待QA批准的任务。我们所做的是，当任务完成后，我们将其移至“准备验证”。然后团队中的另一位开发人员执行QA工作。他会：
如果审核中有不满意的内容，他会将任务重新启动，并且需要先修复它才能进入另一个QA会话。
我们当中没有人真正了解QA，但在介绍验证后我们的代码质量有了提升。
答案 1 :(得分：12)
听起来你正在做很多正确的事并提出正确的问题。
在过去的三年里，我一直在2-4人的开发团队工作，没有任何正式的质量保证。我们有非常满意的客户和低虫数。
这对我们有用，因为：
所有这一切，质量最终都是关于满意的用户。在抽象讨论质量（并争论变量名称）时，我试图让人们回到这一点。最终它应该是关于软件如何解决用户问题，而不是崩溃只是第一步。
答案 2 :(得分：8)
首先，如果您还没有这样做，我强烈建议您设置一个也运行单元测试的自动构建，最好使用代码覆盖来检查是否存在需要更多单元测试覆盖的区域。我不是要求100％代码覆盖率的忠实粉丝，但只有大约60％-80％的东西可能需要调查。
我曾在手工完成日常构建的团队中工作，而构建构建的开发人员也必须执行集成工作，因为签入条件常常是“它构建在我的机器上”。获得自动构建，每次签到或至少每小时一次，并要求签入打破构建的开发人员修复它是朝着正确方向迈出的重要一步，并且（希望）确保随着时间的推移提高质量。
我发现代码清洁度很难从外部给团队留下深刻的印象。从某种意义上说，这听起来你在做什么 - QA角色清理代码？ - 但也许我弄错了。如果我没有弄错，我想你需要改变它。质量不是你能够或应该在事后想到的事情，制定代码的人应该努力实现质量目标，代码审查应该突出原始开发人员需要改进代码的领域，但没有“QA”人“进来清理它。如果我误解了这一点，请道歉，但如果这是你的过程的一部分，那么现在需要改变 ，因为你做的相当于妈妈正在清理这个凌乱的少年卧室。
答案 3 :(得分：6)
在一个小团队中，最重要的是选择你能找到的最好的人，并且不惜一切代价避免任何破坏你的开发团队的人。如果你已经有这样的人，请摆脱它们。
我发现以下所有内容对于在有或没有正式QA角色的情况下保持质量非常有用：
其中，自动化测试是最重要的，其次是同行评审。我没有发现组代码演练值得花费时间，但是在办理登机手续之前或之后的一对一评论通常是值得的。如果检查确保相对较小并且没有结合许多不相关的更改，则签到审核最有效。
个人分支允许开发人员在不准备合并的情况下进行多次签到而不影响其他开发人员的工作，但经常合并以避免被测试分支中未被注意的问题。
答案 4 :(得分：2)
定期审查变更集很好;然而，查看代码，然后使用变更集将相关工作项中的响应写回并将其发送回开发人员可能过于耗时，或者电线可能会越过。代码审查是可行的方法。
完成一大堆代码/功能后，在开发人员和每周指定的QA开发人员或其他开发人员之间安排代码审查。他们可以坐下来查看代码，实现者可以通过他们已经完成的工作，为什么他们这样做完成等等。这样，审阅者可以查看代码，而不必花时间尝试理解“为什么有他们这样做了吗？“通过这种方式，审阅者还可以建议其他更好的方法来执行某个例程，或者向实现者传授他们可能不知道的正在使用的框架中的某个特征。
这一切都与学习和传递信息有关;这有助于改进代码。
希望这有帮助。
答案 5 :(得分：2)
我在20多年前做过一些相关的研究。我认为答案没有改变。在一个小团队中，唯一最重要的是多对眼睛在进入项目之前看到代码。我一直在以两种方式成功完成这项工作的团队：
关键代码的小组审核。代码通常由某人其他提供，而不是作者。
离线审核别人的代码。
这些天我很少参与真正必须工作的软件工作（这是我工作的一个缺点，激励不是创建好的软件，而是发布关于我创建的任何内容的论文），但我会可能会添加第三种方法：
我在配对编程方面有很多经验，我认为它更适合解决难题而不是质量保证，但它总比没有好。
答案 6 :(得分：2)
无论是小型还是大型团队，QA（包括测试）功能都应独立于开发功能。如果开发经理可以控制质量保证，那么就会出现利益冲突，因为开发经理通常会想要发布产品以满足他/她的目标（通常与时间有关）。在QA \ QC向开发经理报告的组织结构中，我们将此QA \ QC称为“工程服务”（测试，文档），而不是所交付软件的独立验证\验证（IV＆amp; V）。
答案 7 :(得分：1)
质量保证部门的目的是确定和：
培训不了解软件质量的人员
重新分配（或解雇）不关心软件质量的人
因此，它是一种专门的人力资源形式，一旦你的人力资源部门增长到3人以上就会考虑增加。如果你知道在你公司工作的每个人的姓名和能力，你很可能每周120分钟比一般的全职专家更好。
这忽略了“QA文件”本身就是可交付成果的情况（例如一些公共部门合同），在这种情况下，您可能需要一个人来做这个，而另一个人做QA。
答案 8 :(得分：1)
在我离开学校的第一份软件工作中，我们根据客户的规格生成了大量数据。至关重要的是，这些数据是正确的，因为数百万美元依赖于它们中的每一个。我们有一个由三人组成的小团队。一个人会编写/修改代码来生成数据文件。第二个人将编写/修改代码以验证数据文件。第三人将通过故意破坏数据文件的副本进行认证，以确保验证程序捕获并正确报告所有类型的错误。我们轮流穿过这些位置。
如今，我在不同的领域做软件，我们组织的东西有点不同，但仍然试图从一开始就建立质量，所以我们以后会遇到更少的问题。我们有一个测试团队，他们的工作就是破坏我们开发人员的自负，但没有质量保证部门。但是，建立质量没有灵丹妙药。对我们现有团队有所帮助的一些事情包括......
我不是测试人员，有很多我不知道的事情。然而，我接受教育的第一课是，写的通过测试毫无价值 - 必须写成失败。
希望这会有所帮助。 希望这会有所帮助。
答案 9 :(得分：0)
听起来你正朝着正确的方向前进，我相信你正在使用一个错误/问题跟踪系统。以下是其他一些想法。
如果您正在使用GUI软件，则可以编写测试脚本，也可以进行临时测试。与此相关的陷阱是，作为开发人员，您所做的一切都是白盒测试，因此您可能偶尔会问一些对软件知之甚少的朋友或家人，只需很少的指导就可以解决这个问题。
使用GUI软件可以做的另一件事是获得一个自动化工具，可以随机点击鼠标并按下软件按键，并让它长时间保持运行状态。令人惊讶的是，可以找到多少错误。
如果你有一个备用盒子，你可以设置自动构建，每晚，每小时，甚至在每次登记后完成，甚至在这些自动构建上运行单元测试。
我曾经做过的最大单一质量提升是在意外向客户发送非功能性版本之后发生的。将鸡蛋刮掉后，我们提出了一份正式的六页检查清单，用于创建和验证版本，从不同的构建和测试机器开始，每台机器都安装了新安装的操作系统和适当的，定义良好的工具。有三个不同的角色（构建工程师，测试人员，发布工程师），交叉检查，每个人在完成它时负责他们负责的每个步骤。如果有任何事情没有完全按照计划进行，我们解决了问题所在并重新开始。对于大多数项目来说，花了大约4-8个小时，当事情不起作用而我们不得不重新开始时，我们有时候会很晚，但我们再也没有发过一个片状的发布。
答案 10 :(得分：0)
您可以设置一个执行静态代码分析的服务器，例如Sonar。它可以配置为每天检出并构建一次代码，并对代码运行不同插件（Checkstyle，Findbugs等）提供的语法和语义检查，并生成良好的HTML输出，以便团队中的每个人都可以查看发现的潜在问题在代码中。
但请注意，可能存在误报。