在测试书籍中有一句这样的话：软件测试目的是用最少的人力、物力、财力发现最多的软件缺陷，提高软件的质量。为达到此目的，除想方设法提高测试的效率，同样对测试过程中出现的各种浪费现象的关注也是不可缺少的，在测试过程中最容易出现以下八大浪费现象。
1.过多的执行
我们都在担心测试不够全面，测试覆盖不全。因为我们知道过少的测试是犯罪，但同样过多的测试是浪费。设计测试用例本意是为了规避测试的随意性，让我们测试时既不多测也没有少测。
很多测试同行都提到在总结测试的时候认为在测试过程中有些功能可以不需要测试得那么详细，有些用例存在的意义很小。将容易的、明显的模块、功能进行详细的测试而复杂的功能没有得到充分测试，这属于明显的资源分布不均导致的浪费。
更有测试成员跟我说，测试用例宁可多不可少，就算里面有重复的用例也不要删除，有了总比没有好！我绝对被这个观点雷倒了。同样被雷倒的还有在编写测试用例的时候，先写多在评审时删除多余的用例。可是骚年，你在浪费整个项目宝贵的时间呀。
过多的执行偏偏有些时候我们还理所当然，认为多测是必要的。如果我们这么认为，那测试就是没有长进的，因为如此我们就不会去优化自己的行为，测试能力将停滞不前。
2.超出范围的测试
漏测风险是一直存在的，这对于几乎所有的测试人员都是噩梦。为了怕承担责任就去做超出测试范围的事情，扩大测试工作量，而不是去分析测试边界、测试重点。反而在测试工作中理所当然的存在，形成了极大的浪费，而且这也不是一个追求卓越的测试人员应有的态度。
3.过多的测试文档
在编写文档的时候，首先要明白相关文档的作用，如果只顾编写而忘记编写的本意了将导致极大的浪费。文档最重要的作用是保证信息传递的有效性、便捷性，保证文档在查看过程中信息不失真。如果文档在辛苦编写后再无查看，那么该文档就失去了存在的意义。大多数IT人员不喜欢的事情就是写文档，最不喜欢的事情就是写完全没用的文档，最最不喜欢的事情是文档不但没用还要求做得非常工整。
也碰到在编写测试用例时候要求测试步骤要求写得非常详细，让不懂测试的人也能执行。
也碰到过执行用例的时候，将所有过程、结果截图以规避测试风险。
对此，我由衷的感慨：你们辛苦了！
4.沟通上的浪费
敏捷中有一个重要准则是：无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。听到过这样的真实案例：明明在同一个办公室，转个身三两句话说完了，偏偏用个QQ在聊来聊去。不合理沟通机制（如缺陷管理流程制定不合理），甚至网络不畅通，也会引发沟通上的浪费 。
5.等待
等待是测试现场最容易出现的浪费问题。往往很多场合下都会出现等待的情况：任务的前置条件未达到导致工作无法开展，关键任务的阻塞导致相关任务不能正常进行，甚至因为测试人员权限（权力）不够无法自主开展工作等情况产生的等待。
等待的情况普通存在，对测试工作的正常进行有直接的影响。等待的累计时间越长，测试的风险也就越大。因此，应该统筹规划，合理组合各个不同的工序，将等待的时间减少到最低限度。
6.管理上的浪费
管理的目的是使工作处于效能最佳的受控状态，防止、处理和解决出现的问题。当然很多企业在管理上存在着误区：为了管理而管理。如果为了管理而管理，必然要增加很多人为的障碍，反而适得其反地导致效率降低。
常见的在管理上的浪费有：开没有价值的例会，任何分配不合理、不公平，领导者权力过于集中，管理者不能解决冲突和矛盾，工具引用不合理，流程机制不适用都可能造成管理上的浪费。
7.动作浪费
恰当、合理且效能最大的动作有助于提高效率，减轻测试人员的身体疲劳。虽然软件测试工作是一项脑力劳动，但恰当、合理的动作能缩短测试的时间。
我们知道，电脑键盘就是通过研究用户动作而将26个字母进行了重新排列，以求达到最快的输入。我刚在学习计算机的时候，老师就要求我们指法正确、盲打，基本功的学习为提高输入效率和输入准确率产生了很大效果。快捷键的使用，用例执行顺序的优化组合都可以提高测试的效率。
通过对测试行为进行动作分析，总结出最合理的动作，避免出现无效能动作的浪费现象，从而缩短测试的时间。
8.返工
著名的质量学家菲利浦 克劳士比在其经典著作《质量免费》中提到高质量就是第一次将产品做好，如果因为第一次没有将产品做好而造成的返工将导致成本的增加，同样造成浪费。