在代码的开发完成且构建分发到测试人员手中时，实际的测试开始了。针对应用执行每一个测试案例，成功/失败结果被记录下来。同时，用屏幕截图截取结果 。 任何缺陷都被用缺陷跟踪工具（例如Rational ClearQuest、Mercury Quality Center或其他缺陷跟踪工具）记录下来。缺陷跟踪和缺陷解决需要有一个适当的过程。典型情况下，当测试人员在测试跟踪工具中记录一个缺陷，如果可能要包括测试的阶段、主题、问题的描述、重复的步骤及屏幕截图。问题的描述需要记录需要修正的错误是什么和错误在什么地方，而不是一条讨论的记录，因为没人能去确定那是否一个问题。我曾看到SharePoint站点被用来做缺陷跟踪。当这样的一个站点被使用，当缺陷被发现时，需要记录测试的阶段。甚至当你使用Rational ClearQuest和Mercury Quality Center，也要根据组织中使用的软件生命周期的类型来确定是否记录测试的阶段。

　　根据缺陷的严重性，需要修正找到的缺陷，并为此建立一个新构建。测试人员重新测试缺陷来确认它已经被修正，然后在缺陷的功能区域执行一个轻量的回归测试，确认没有其它问题被引发。一旦测试人员通知团队内容测试已经完成，依赖于软件开发生命周期，代码被作为产品发布，或根据需要发布到测试网站上做现场测试。如果测试网站发现有缺陷，将缺陷报告给开发团队，新的构建将被发布，然后先经过内部测试，再发布到测试网站。缺陷像以前一样被记录下来。

　　自动化测试

　　在自动化测试中，一份自化测试计划被编写出来，用于概述自动化将如何执行及被选中的测试方法。它可能是被用来完全替代主测试计划，又或者仅和主测试计划一起被编写。一旦文档被编写后，自动化测试脚本开始对应软件需求规格和需求研究文档中的需求进行编写。在构建被分发后，测试脚本针对应用运行来检查是否存在问题。如果确实是一个缺陷，那么缺陷被用和手工测试一样的工具记录下来。依赖修改的数量和严重程度，一个新的构建被分发，并再次针对应用运行自动化测试脚本。一旦测试人员发现已经不存在缺陷，他/她可以报告测试已经结束，构建已经可以成为产品。

　　可改善的问题点和领域

　　1、建立对软件质量保障测试人员的信任??我的一个开发经理有一次告诉我，项目经理需要很长时间才会信任测试人员。幸运的是，我碰到了这种特别的情况。但是让开发团队信任测试人员将会尽职尽责去执行工作有可能是困难的。那意味着，他/她将找出或揭露所有关于项目相关的事和可以帮助他或她完全测试项目的编码。很多时候，通过增加交流，并向项目经理和开发者解释为何要执行这些特别的活动，这个问题可以被克服。

　　2、开发人员不相信软件测试和质量保障的价值??测试人员会经常面对着和开发人员冲突的情形。 通常来说，这来自一种已过时的想法，测试人员并不知道开发人员所做的事或者没有人能测试系统。可事实是，测试是一种技能，而且人们花费了很多年来完善测试软件产品。有些时候，测试人员只有依赖于让一个有地位和背景，更测试人员去告诉开发人员，让他们去看测试人员发现的问题。

　　3、测试时间不足??很多时候，仅仅是项目计划中没有足够的时间进行充分的测试。一个解决这个问题的办法是在需求被编写时同时测试它，并在需求被编写时，构建测试案例。另外要做的事是找一个能够评估项目和分发日期的人。另外，在软件开发项目中，人员常规例会有助于鉴别出关键人物。

　　4、糟糕的需求撰写??有时候，需求没有被正确的捕捉，并在软件开发项目过程中需要修订。这种情形对于组织和测试团队的钱和时间都会有耗费。这种情形会导致范围渐增（Scope Creep），从而使分发的代码超过需求中所编写的内容。对此问题，并没有一种真正的解决方案。好的方法是当发现范围渐增发生时即时制止。一个方法是通过获得用户在软件需求规格上的签字，预先使得决策变得稳定，这样范围渐增不会发生。另外一个制止它的办法是，有一个变更控制委员来批准软件需求规格变更。改由变更控制委员来对费用超支负责。这避免了项目经理由于范围渐增而遭责难。

　　5、没有足够的测试资源??这个问题是需要高层去处理的情形。当没有足够的测试资源，它会影响到时间表，并且会导致那些过少的测试项目的测试人员们筋疲力尽。

　　6、测试人员没有足够的培训??这种情形会导致测试人员不能理解正在测试的软件。它会影响到需要的测试时间和涉及到测试成果的金钱。

　　7、计划将来的测试成果??当正在进行当前版本的测试时，同时进行下一个计划的版本的时间制定，这个问题会浮出。对于测试人员来说，正确的评估时间和将获得测试效果是困难的。