传统的软件测试，开发人员完成编码后，交付给测试人员，这种模式下，测试人员不能及早发现需求阶段的缺陷，同时测试工作的开展也滞后了，产品质量得不到有效的过程控制和分析，总体进度可能会由于返工问题造成拖延。
如今的软件测试，测试在做什么？
首先是需求阶段测试在做什么：
参与stroy分析、评审，需求澄清，记住一点测试永远要比开发更了解业务。开发需要stroy评估，测试也需要stroy评估，排除技术上的问题把业务放在第一位。
再就是编码阶段测试在做什么：
功能要点确认的过程也就是需求澄清的过程，只有开发与测试对需求功能点没有异议，后续的工作才能顺利的进行。
测试用例的设计前提是明确了需求，以功能实现、业务逻辑、数据流程为原则设计测试用例。测试用例按项目要求分清等级，一级用例为主流程用例，也是开发人员自测用例。二级用例为功能分支用例，在不影响主流程的前提下功能堵塞、功能未实现用例。三级用例是异常行为用例，包括性能、安全、用户适应度等问题。分清用例等级可以更有效的管理统计测试结果。
用例评审是必不可少的环节，可以帮助测试人员补充遗漏问题和解决分歧问题。
测试探索是进行了功能要点确认和用例评审后，为了保证测试场景的覆盖率，需要再进行测试探索。在开发人员完成雏形之后，使用探索式测试的策略，对功能基本流程进行有目的的快速走查，挖掘功能不确定的地方和补充测试场景，避免不确定的因素拖延到开发阶段后期，造成返工。
功能测试、Bug Tracking、回归测试、系统测试、验收测试都是日常测试工作所需环节，不再一一说明了。
测试完毕，测试还需要做些什么？
一：测试报告：
完成验收测试，提供测试报告，给出测试数据度量，例如：
1) 测试发现缺陷总数：测试过程中产生的去除状态为“无效”、“不用改”的缺陷数目。
2) 测试发现严重缺陷数：测试过程中产生的并去除状态为“无效”、“不用改”的、且严重性为“Major”和“Critical”的缺陷总数目。
3) 测试发现缺陷修复数：测试过程中产生的状态为“已关闭”的缺陷数量；
4) 未解决缺陷数：去除状态为“无效”、“不用改”、“关闭”的缺陷总数。
5) 缺陷修复率：（测试发现缺陷的修复数）÷（测试发现缺陷总数）×100％
6) 严重缺陷率：（测试发现严重缺陷数）÷（测试发现缺陷总数）×100％
7) 严重缺陷修复率：（已修复的严重缺陷数）÷（测试发现严重缺陷数）×100％
8) 测试需求覆盖率：已测试需求个数÷需求总数×100%
二：缺陷统计分析报告
另外，测试人员还有一项重要工作，对当前版本的缺陷进行统计分析：
按缺陷级别统计：
测试进度和问题分析：
1、从BUG的严重级别分布来看，Major级别以上的BUG占12%，占的比重不高，说明大部分的主要功能已经实现了；
2、其中在sonar定义级别的缺陷，主要集中在代码规范和单元测试覆盖率，说明代码质量有待提高；
3、版本测试的前期时间较充足，后期随着开发提交完成的功能点增多，BUG数量增多，剩余测试时间变得紧张；
4、在版本测试期间，发现测试环境存在一次代码被覆盖、两次因开发人员操作失误影响测试执行的情况；
小结：
测试人员应当持续反馈、改进、总结每个版本发生的问题（不管是缺陷，还是过程中出现的），并对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。
敏捷测试团队，不再仅仅是在coding之后。而是和研发人员贯穿在需求分析、规格说明、自动化单元测试、自动化验收测试、静态代码分析、技术债等环节中。所以敏捷项目必定在将来效率的趋势下成为主流。