质量很重要，毋庸置疑的。但是进入新时代-- service -based software 的大量普及，软件测试所处的环境发生变化，是值得软件测试人员思考， 认真思考一下。
“测试之死” 并不仅仅是一个噱头。
首先看看软件测试所在的环境变化：
1. "fix defect " 的成本变越来越低成本。
传统的软件发布是基于一个软件包（package），有时很大，需要四五张光盘才能安装。软件发布出去后，如果有严重问题，需要修复，那是个很头疼的事。想想丰田汽车如何被召回的。现在软件运行在浏览器，有问题只需要改一下服务器，甚至不需要重启就直接修复了。 比较一下二者的成本，就这到为什么传统的软件测试人员千方百计的在软件发布前找到尽可能多的缺陷。而现在，主要矛盾已经由软件质量本身的担忧转移为对软件发布的速度上面。
2. 软件持续发布。
持续发布，跟传统软件一年一发布策略有着天然的优势：反馈快速快，应对需求变化快，更好让用户参与，提高交付满意度等等。 比如现在用的chrome，3年多发布17个版本。然而这些对软件测试提出了新的挑战，测试要快，至少不能拖慢开发节奏。如果测试影响软件发布的时间，这是不可接受的。传统软件测试，耗时耗力。尽管自动化测试的呼声，以及对应的想法，工具，数不胜数，但是面对如此短的发布周期，软件测试人员已经有点吃力。
3. 软件的测试理论没有什么重大突破。
几十年来软件测试连最基本的问题都解决： 比如软件质量的定义？ 软件测试的充分性？ 软件质量的评估？ 如何保证测试用例本身的质量的衡量？
4. 软件测试回报率低。
传统的软件测试需要专职人员，并且软件测试成本高：需要买系统，搭环境，写用例，自动化，分析及报告，以及最终的维护。这是一个大投入，回报率却不见得都是那么高。更何况现在，系统，测试环境，用例实现，分析报告，这些都可以统统自动化起来（continous integration or continous deliver). 软件人员的依赖还需要那么多吗？
5. 测试只验证软件的正确性。
测试，很大程度只是测试软件本身是否满足需求。但是对于软件需求本身对不对，软件测试却很少覆盖到。 Tseting just verify the thing right， but can't verify the right thing. 这本身不仅仅是软件测试者的问题，比如测试人员基本很难和最终客户交流。 然而总正确的事比把事情作对，重要的多。这需要测试人员向领域专家靠拢，但是现阶段这样的测试人员很难具备这样的技能。
6. 敏捷鼓励更多的开发人员尝试一些测试。
敏捷里面的软件质量是有整个团队负责，并提出一些方法鼓励开发人员去做测试：Unit Test，TDD，甚至希望开发拿出20%的时间来做软件测试。甚至开发人员交互测试。
7. 结果导致市场上对测试职位越来越少，或者外包出去给utest 去做。 自己仅此感觉。
软件测试的从业者，何去何从？
1. 转化为开发人员。
不少测试人员本来就是开发人员，对于他们而言不是难事但是他们还会转回去吗？而对于那些手动测试者而言这条路难度有点大。
2. 转化为领域专家。
这个需要积累，不是一撮而就的。熟悉自己产品，到熟悉整个行业，最后变成领域专家。
3. 转化为软件运营人员。
熟悉自己的软件架构，部署，很容易去运营和维护这个产品。但是需要提高这方面的技能。
4. 增强人间技能，自动化测试。
毕竟软件测试还是需要的人来做的，可以做测试方面的专家，自动化测试是一个不错的方向。
5. 其他...（培训，咨询，软件项目中的其他任何角色...)
欢迎大家分享自己对软件测试未来的看法：）
来源：http://www.cnblogs.com/zhyg6516/archive/2012/03/08/Roc.html