尽管单元测试通常足够好，但很高兴看到开发人员确保他们从头到尾运行了一个流程，而不仅仅是单元测试。由于应运行的测试类型因应用程序类型而有很大差异，因此我将与产品的测试联系人进行讨论。

对于我来说是新开发人员，我通常会问他们是否愿意在没有经过 QA 测试和对任何缺陷负责的情况下在生产环境中安装软件（从不认真对待它）。这往往会让他们想到我什至没有想到的测试类型！

对我来说效果很好的是以下步骤。

1. 开发人员尽最大努力编写好的代码。
2. 开发人员从另一个开发人员那里获得代码同行评审
3. 开发人员运行他们的单元测试，并检查它们是否都通过了。
4. 开发人员和测试人员坐下来进行审查：
   • 开发人员与测试人员一起走，让他们知道正在交付什么、任何相关的更改以及任何尚未完成的区域，这样就不会在这些区域中记录错误。
   • 测试人员运行他们为该功能编写的测试。这允许开发人员审查测试并确保它们有意义。
   • 测试人员需要几分钟来执行一些高级测试，并与开发人员一起完成该功能。任何明显的错误都会在现场修复，无需将它们记录到系统中。
   • 审核完成后，开发人员签入
5. 然后，测试人员在接下来的每日构建中正式测试该功能。

虽然在纸面上这看起来真的很繁重，但我们发现它非常有效地清除和修复了很多明显的问题，因为我们还没有接触到缺陷跟踪系统，所以我们还没有接触到缺陷跟踪系统，而且从长远来看，这可以节省每个人的时间跑步。

对于开发人员在移交给 QA 之前应该进行什么样的测试，没有硬性规定。这取决于开发人员、QA 团队、组织和产品。测试是达到目的的一种手段，而不是目的本身。

重要的是要注意 QA 收到的质量和发布产品的质量。如果这些时间点的质量不是您想要的，您的组织需要查看问题出在哪里。问题可能出在编写大量错误的特定开发人员身上，但也可能出在脆弱的第三方包或一组模糊或不稳定的需求上。

根据经验，以下是开发人员在移交给 QA 之前应测试的优先级列表：

• 该产品仍在构建中。
• 产品仍会安装。
• 冒烟测试通过，即对最基本的测试类型至关重要的产品部分仍然有效。
• 最积极的明显测试用例（无论定义如何）都有效。换句话说，如果您只是想使用该产品，它应该可以工作。
• 负面测试用例都有效。换句话说，如果有人试图破坏产品，他们就做不到。

我也坚信开发人员同行评审的想法。自从在我的工作地点采用这种方法后，工作质量显着提高。同行评审提供的新视角经常寻找更有效的方法来编写代码或发现本来会被遗漏的错误。

这表示始终存在可用资源/项目规模的问题；一个小团队可能无法在维持正常工作流程的同时有效地对所有新功能进行同行评审。

此外，尽管这听起来很明显，但我鼓励您清楚地告知测试人员您对代码所做的所有更改（无论多么小）。无数次实现了新功能，但由于相关工作项从未更新足够具体的细节，我从不知道新功能的存在；直到我在探索性测试中偶然发现它。

如果您的测试人员有大量自动化测试（因为最小的更改可能导致这些测试开始失败），这一点就更重要了。