Joel Test是一组非常简单的问题列表，可以非常快捷的来评审软件团队的开发过程。最早是由Joel Spolsky发布在其网站Joel on Software上面，尽管Joel宣称它是“一个不太靠谱的、粗糙的来评定团队的测试”，但是它被软件管理者、面试主考官还有软件投资者广泛使用。
下面是问题列表:
1. 是否启用版本控制？
2. 是否可以一步构建?
3. 是否进行每日构建？
4. 是否有bug跟踪列表？
5. 是否在修改bug后，才开始写新代码？
6. 是否及时更新工作计划？
7. 是否在开发前编写了大家一致认可的功能文档？
8. 是否给予团队安静的工作环境？
9. 是否在使用最好的软件开发工具？
10. 是否有专职测试人员？
11. 是否在面试时以实际编写代码来检查求职者？
12. 是否利用陌生人进行可用性测试？
这里重点关注几条：
5. 是否在修改bug后，才开始写新代码？
微软制定了“零缺陷策略”。其真正含义是：在任何时候，都要把解决现有程序里的问题作为首要问题来抓，然后再去写新程序。
为什么要这样做呢？
第一条：越早解决问题，越容易解决。
第二条：刚写的程序里发现问题，你能够比较容易地估算解决它的时间。如果你的开发过程中有许多虫没有及时解决，那你的开发计划肯定不可靠。反过来，如果你们已经把已知的虫全部解决了，要做的事只是写新的程序，那你的开发计划就会比较准确。
第三条：把已知的虫全部解决，这样做还有一个好处：保持“让开发中的产品随时处在可以交给用户的状态。如果你的 竞争对手推出一个新的功能想把你的客户抢走，你可以马上在你的产品里加上这个功能，立刻将新产品交付用户，因为你没有一大堆积累下来的问题要解决。
12. 是否利用陌生人进行可用性测试？
这句话的意思是，让你从走廊里随便抓几个人来试用你的软件。如果你抓五个人来用你的软件，那就有可能发现95%的可用性问题。
得分：
对于每一个问题如果回答“Yes”，可以得一分。12分是优秀的团队，11分可以看成刚刚及格，这些都是最基本的问题，缺一不可。尽管一些大的团队例如微软可以得12分，但是许多团队只能得2到3分。
这个问题列表是Joel在2000年做的，十年过去了，Joel Test Update for 2010 诞生了。
下面是新的列表：
1. 是否采用了配置管理系统？
需要定义一个配置管理系统，除了对源代码进行版本管理外，还应该包括建立代码分支、定义分支合并策略，版本稳定策略，产品部署计划，系统角色和权限定义，还有每个阶段的质量检验关方法（quality gates）。
2. 是否每个人都可以一步构建？
3. 是否每日构建中添加了自动测试？
4. 是否将Bug数据库与源代码管理集成？
一个Bug的修复对应着那些代码的改变？每一次代码的改变是否关联着一个Bug或者开发任务？一次代码分支的合并关联着那些Bug？ 每一次代码的提交应该修复某个Bug或者完成某个开发任务，我们可以通过Bug报告来查询代码中的改变。换句话说，源代码管理应该与Bug追踪、项目任务追踪集成。
5. Do you fix bugs and write new code?
通过建立代码分支、以及分支合并等等手段开发团队可以将同时进行上一次发布的Bug修复和下一次发布的代码编写。质量保证团队必须要确保在上一次的发布版本中Bug能够被修复，而且要能够将修正代码同步到当前的发布版本。
6. 是否能够追踪任务并且管理变化？
7. 是否拥有一个需求管理系统？
需要支持需求功能文档的变更管理。我看到很多的开发团队有着很好的文档编写开发流程，但是文档的变更管理流程却很糟糕。
8. 是否给予团队一个安静的工作环境以及一些作战室？
9. 是否在使用最好的软件开发工具？
10. 测试人员是否参与到需求管理中？
11. 是否在面试时让求职者评审实际代码？
12. 是否利用陌生人进行可用性测试？
怎么样看看你所在的团队情况如何？