1、回滚测试
如果你正在处理现有的一个被修改和放回生产中的应用，QA应该进行回滚测试以确保新内容已经被引入应用中以继续和该应用使用的其他系统资源工作。一个很好的例子就是应用中的数据字段突然发生变化——只有应用访问的数据库中相同的字段没有变化。因此，当数据库尝试访问的时候，该应用就会出现问题。向后进行兼容性检查的QA测试将会找出像这样的问题。
2、压力测试
一个应用每秒必须处理来自任何地方的数千次交易，任何时候都应该经过最大交易负载的压力测试，模拟这个应用在生产过程中需要提供什么支持，这样QA就可以验证该应用是可以应对这个负载的。如果应用运行在互联网上，压力测试的边界也应该从交易执行的地方扩展到全球的互联网节点。有时候在不同地区的互联网带宽或者服务是有限的。当应用在压力测试中出现故障的时候，可能意味着必须给这个应用分配更多的处理能力或者存储空间——或者必须开放交替的互联网通道以实现能够支持特定地理区域所需的带宽和服务水平。通过在压力测试场景下与网络专家和应用开发者的配合，QA可以识别这些潜在的检查点，这样就可以在部署应用之前解决这些问题。
3、安全检查/压力测试
基础的用户名/密码检查是由QA部门在日常工作中执行的，但是检查后门漏洞并非如此。尤其是如果这个应用是高度机密的应用，QA就应该与网络专家和安全专家合作，在检查过程中尽可能多地做好安全防控。
4、用户友好性/用户测试
即使一个应用可以正常执行设计好的功能，但是如果用户无法理解或者无法使用的话，这个应用就是没有多大用处的。这意味着对于QA来说，在应用测试中与最终用户配合以确保该应用的人为因素和可用性检查是很重要的。如果不这么做，应用就不会被使用。
5、文档的完整性
文档通常是应用开发中第一个被忽略的一部分。对于新开发的、需要马上上市的应用来说这可能没有什么问题。但是到了修复或者增强应用的时候，任何追随应用最初开发者的人都会把时间花在试图看懂代码和应用执行的所有内部功能上。作为QA检查离别的一部分，QA应该检查应用文档的完整性。
6、用户支持
在部署应用之前，IT帮助台和应用的企业用户应该围绕着该应用的工作做一个完整的培训——应用文档（见第5条）应该是完整的。
7、业务流程检查
如果一个新应用要改变业务处理流程的话，那么在这个应用上线之前，应该在最终用户部门进行一次演练检查。完整的演练确保每个人都要知道新应用和业务流程的改变。例如，在过去，银行借贷部门的承销商自己决定是否发放贷款。但是现在，会有一个新应用来评估每个贷款申请，并返回一个带宽决策，让承销商只有在主管批准的情况下放贷。这是一个业务流程，也是应用带来的改变，因此那些分配到做这项业务的人，必须在应用投入生产之前了解新的应用和新的业务流程。
8、如果设置有关键绩效指标（KPI）的话需要确认指标
一些新应用和新系统被快速开发出来以改善收入流、降低成本或者加快决策时间。如果特定应用有可衡量的KPI，并且是可行的话，QA应该测试这个应用是否满足最终业务以及/或者IT已经预先设定的指标。
9、代码标准化
大多数IT部门有应用代码的标准化指导方针，以及所有开发者都应该使用的通用目标和例行程序库。QA检查的一部分就应该包括检查代码以确保应用符合公司的标准。
10、多个用户界面（UI）的部署
如果应用将要部署在各种桌面和移动设备上的话，该应用的用户界面外观和大小应该针对每种设备都是不同的。QA应该检查这些不同界面在各种设备上的可使用性，并检查如加载时间等因素。
