那么，如何做一个社会化的测试工程师？

　　第一，不应把测试局限在功能是否实现上，要更多的关注非功能性测试。

　　如果看ISO 9126软件产品度量模型，我们就会发现，软件功能性只是评价指标中的一个元素。除此之外，软件质量还由易用性、易学性、可靠性、效率、可维护性、部署特性等。我们当前的软件开发、设计、测试都过渡的关注功能是否实现，在花费大量的资源给软件堆砌功能以后，我们的软件变成了由树形菜单、和分级目录组成的怪兽。我们的每个测试用例都需要点击三级按钮才能找到功能页面。但是，我们是走在正确的道路上吗？我们忽视了一个很重要的事实，那就是：用户不会用一个不好用的软件，即时它的功能100%正常。

　　更不要说，文中第一个例子给用户带来的“伤害”。

　　我三岁的孩子和七十多岁的奶奶一样可以用ipad，但是她们都无法在没有我帮助的情况下，从Windows7上找到想要的东西。

　　再看树形菜单和分级目录的始作俑者，微软公司，其最新的操作系统、Office、手机操作系统、UI都无一例外的抛弃了树形菜单，转而使用Metro UI。

　　作为测试工程师，作为研发团队中和“人”最接近的那个人，我们对这些非功能特性的掌握程度，决定着我们未来的发展方向。

　　从软件研发的历史看，自动化测试、测试工具的发布、测试模式的变化，都没有从根本上改变软件的面貌，它们只是在软件规模越来越庞大的历史里，如履薄冰的保护着软件的基础质量。由于缺乏易用性、可靠性、易学性等等非功能性测试的量化评估手段，我们对这些测试的研究和实践还停留在表面。

　　放眼未来，能在非功能性测试上走的最靠前的软件公司，他们的软件更有可能成功。在ISO组织的软件易用性测试前言的草案中，第一句话就是：当今几乎所有软件公司的软件都面临着易用性问题（苹果公司除外）。纵然这是草案作者们的一个玩笑，但是不也正是软件业的现状吗？

　　我想作为测试工程师，如何从测试角度提出对非功能性质量的评估方法，将是未来测试发展的一个重点和热点。

　　第二，应该投入更多的精力去研究业务知识。

　　所谓隔行如隔山，作为接收过系统信息技术教育的工程师，我们的IT知识应该说是足够的。但是我们对于用户所在领域的业务了解还远远不够：

　　做建筑业软件的不懂力学；

　　做医院系统的不懂药学；

　　做销售系统的不懂会计学；

　　做金融系统的不懂金融；

　　做互联网的不懂广告、传媒、营销；

　　做MIS的不懂管理学。

　　这些现状导致我们的软件还只是“将就着能用”的软件，而不是客户喜欢的软件。在这种情况下，作为测试工程师，与其投入大量的时间去学习Java，不如学习业务知识。计算机技术作为新工业革命的核心技术，不是革了信息技术的命，而是革了整个工业领域的命，所以我们的软件从多大程度上贴近客户，决定了我们的行业如何发展。

　　第三，培养对软件的嗅觉。作为高级测试人员，验证软件功能是否正常不是我们的主要职责，我们需要像灵敏的猎犬一样去嗅软件，发现那些被遗忘的风险、经常出问题的点、被忽视的测试，以及竞争对手们的新动态。所以个人一直都有一个观点，那些连新浪weibo都不让上，工作期间不允许用智能手机登陆移动互联网的软件公司，是无法做出真正一流的软件的，这样的公司只能做些树形菜单和分级目录，并把一些小的Ajax特效当做革命性创新，全然不顾现在的前端技术已经日新月异。

　　作为一个软件用户，我使用各种各样的软件，我同时使用ipad，安卓，塞班，Windows，Mac OS，通过不同平台的比对，我可以体会不同软件的优缺点。这些体会和经验对于我做探索性测试很有益处。

　　同时，我也在观察身边的人是如何使用软件的，一个很有趣的发现是，一个背景不同的用户，他/她对网站、软件的使用可能和我完全不同，所以能发现完全新鲜的bug。这些对于我做探索性测试也非常有帮助。

　　最后，如果学习社会化测试还有一个益处，那就是这些知识不会像编程技巧那样快速更新。十年前，Java工程师无论是地位、收入都远远高于Javascript，PHP工程师，但是现在的状态则完全相反。十年前人们就在为Java完全代替C++倒计时，但是今天，由于苹果公司，C++再度火爆。所以变成语言的潮流变化是很快的，无论你如何学习，都不可能预见到未来的趋势。而业务知识不同，药学、会计学、力学这些知识，在过去十年中的变化要比编程语言小得多。学习业务知识，其风险也比学习一种语言、一种工具要小得多。

　　当然写这篇文章的意思不是说写代码不重要，由于持续集成和敏捷开发的流行，测试团队也需要一些既懂开发又懂测试的工程师，但是我非常赞同测试团队应该有角色划分的做法，我们对于业务背景的测试人员的重视程度现在还不够。

　　我们的行业必然需要那些在易用性测试、可靠性测试、客户测试、业务知识上有专长的人，希望未来这些人就是你。