软件检查过程通常需要检查表，仅是为了向审阅者提供提示和一些建议，以在软件产品的检查过程中确定和识别缺陷。检查过程应始终由一些常见编程错误的清单驱动。
检查清单只是对已检查特定软件产品的保证。应通过与一些经验丰富的人员讨论来制定检查清单，并应定期更新，以从检查过程中获得更多经验。指南通常仅包含清单，用于各种工件，例如设计文档，需求等。
不同清单还制备了各种编程语言即对于源代码清单为不同的源语言分别给出。清单中有些项目是一般性的，因此需要大量的人为判断。下面给出了在检查过程中可以进行的一些检查：
- 数据故障：
- 检查程序的所有变量在使用它们的值之前是否已初始化?
- 是否已给所有常数命名?
- 有没有缓冲区溢出的机会?等等。
- 控制故障：
- 每个条件陈述的条件是否正确?
- 每个循环是否一定会终止?
- 复合语句是否正确括在括号中?
- 输入/输出(I / O)故障：
- 是否使用了所有输入变量?
- 在将所有输出变量输出之前，是否已将它们分配给一个值?
- 可以输入那些意想不到的腐败原因吗?等等。
- 接口故障：
- 所有方法和函数是否都具有正确数量的参数?
- 参数的类型，即实际匹配和形式匹配吗?
- 参数是否以正确的顺序显示?
- 如果所有组件都访问共享内存，它们是否具有相同模型的共享内存结构?
- 存储管理故障：
- 如果修改了链接结构，是否正确地重新分配了所有链接?
- 如果使用动态存储，是否已正确分配空间?
- 不再需要空间后，是否会明确取消分配空间?等等。
- 异常管理错误：
- 是否考虑或考虑了所有可能的错误条件?
例子 ：
- 需求检查清单：
- 需求是否在功能和数据之间表现出明显的区别?
- 需求是否准确定义了需要显示给用户的所有信息?
- 需求是否解决了系统和用户对所有错误情况的响应?
- 是否明确，简洁，明确地说明了每个要求?
- 每个需求都可以测试吗?
- 是否存在任何含糊或隐含的要求?
- 有任何矛盾的要求吗?
- 是否存在需要在软件需求规范(SRS)中未解决的领域?
- 是否规定了性能要求，例如响应时间，数据存储要求等?
- 错误处理和恢复清单：
- 是否有足够的错误条件测试?
- 是否在存在错误的可能性很高或错误的结果对系统致命的情况下测试了错误条件?
- 是否已记录所有返回码?
- 所有返回消息都可以理解吗?
- 该程序是否允许成功进行错误恢复?跨模块或过程故障?跨操作系统故障?跨越中断?跨硬件故障?