<不能成为专业软件测试人员的10大理由>终于在两个夜晚苦战到12点多翻译完了，2，3年不接触英文还真是很生硬，可能大家一看就知道是Chinese English，哈哈！只能请阅者委屈一下了，以后我也要多多学习英文啦～
原文作者是之前负责惠普公司QC的一名测试前辈，无意中看到他的文章，有些我觉得还是很在点子上的。所以就当一边学习英文，一边总结测试相关的就出来这篇译文了。
在译文出来之后，有同行伙伴提出了一些疑问，在这里我也结合我的工作实际阐述一下。
1、文章中第二点，深圳的一位网友就提出了：在中国90%以上的中国IT企业很难做到让测试人员在开发早期甚至需求早期就介入。
我不太确定他说的90%是否有数据支持，至少我所认识的很多同行都会在需求阶段让测试人员介入，如果还不是这样，我想测试人员是时候做些什么了吧？？绝不能坐以待毙.我待过2家互联网公司，说说我的经历。一家是创业型公司，一家是中型公司，当时我们是如何做的呢？创业型公司，或许很多这样的公司，都没有较为成熟的文档化和流程，以快为先，唯快不破。没有专职的项目经理，甚至产品经理都没有，我们的CEO，CTO就是产品经理，甚至我们每个人都可以为产品设计贡献思路。老板们的想法已经成型了，很多时候在脑子里，没有文档化，然后开需求宣讲会议，因为人不多，开发测试都会参加，会议上也会有一些讨论，这是大改，还有小改，可能就发邮件给大家，邮件也算是文档吧。大多数时候大家很难在会议上就发现需求的全部漏洞，但是基于对系统的理解，有时候测试人员的思路也很活跃，“可以...不可以...如果...如果不...”类似使用场景的思路联想到的问题可能起到作用。但是不去参加这个会议，可能就只能到了代码写完提交给测试了，这个时候最大的问题就是，如果开发人员理解的有偏差，测试人员如何保证产品的质量呢？只有保证测试的需求与业务需求是一致的，才能真正的说明我们测试的是一款正确的产品。
其实如果不去参加那个宣讲会议，就是那位网友说的情况了。在我看来，在没有项目流程的公司里，测试人员要更加主动，主动承担一部分项目管理的工作。如果没有文档，可以主动申请加入到需求宣讲中去。其实参与到宣讲中，至少还有一个好处，可以知道为什么这么改，有助于我们更加理解业务的初衷。如果是邮件发出来的，可能就没有这么多来龙去脉。
上面说的是业务需求，其实对于开发设计的会议，我当时也是非常乐意去参加的，你会知道他们的设计思路是什么，大致算法如何设计，有哪些异常处理，是否有异常报警机制等等。没错，我能想到的一些use case也会提出来，让他们开发的时候考虑到。这样子，我能更懂产品，测试思路也更宽阔，而且让开发理解我们测试人的思路，如果他们也懂一些测试思路，很多问题在开发设计阶段就可以规避了，这也是尽早测试的意义所在。
再说第二家公司也就是现在这里，流程稍微正规一些，不过也是一步一步建立起来的，测试人员也参与到流程改进中去。有专职的项目经理和产品经理，需求是产品经理事先设计好的，只不过设计的时候可能会阅读原有的设计文档或咨询一下之前负责的开发或测试原来的业务逻辑，这也是为了取其精华去其糟粕，这是需求设计完成前测试人员唯一介入的；当需求设计完成后会发给项目组成员，组织宣讲，会议上可以提出相关疑问，产品经理会记录下来再进行确认或重新设计。之后需求设计freeze，如果不是特别大的问题，其他需求变更可以考虑延后处理，对于严重需求漏洞就需要及时变更，越往后成本越高.之后开发测试人员会依照新的文档开始工作，但是在测试设计用例或开发代码设计时经过更深入业务理解之后可能又会发现需求的一些问题，会集中反馈出来，产品经理一样会酌情考虑是否延后处理.后面的阶段就是进行用例评审，组织测试等等了.总体来看流程比之前创业型公司顺了很多，至少测试可以较早的介入.当然，测试人员参与到流程改进中也是一大保证.至少我的经历来看，项目延期的几大杀手就是需求变更，无流程和糟糕的项目计划.
2、对于第三点中的情况，我想作者的意图也只是想要表达场景法设计用例的重要性，而且场景法设计用例的确是贯彻软件测试的始末.如深圳的那位朋友所说，没有一款产品是需要覆盖100%的，我们的策略都是一定要覆盖重要核心的业务，次要的备选流业务可以通过产品，开发及测试三方评审哪些需要覆盖哪些不需要覆盖，以得出测试的范畴，因为即使测试出了bug，也可能不修复，我想不被修复的bug是没有意义的.而且评审过的测试范围即使某天出现遗漏我们也有说法.
3、对于第一点中谈的代码能力.我个人意见是：这项技能是锦上添花，并不需要每个测试人员都需要具备.但是具备了就可以参与到项目的code review中去，在提测前期就可以发现很多问题，而且具有代码能力的测试人员可能更懂得如何更有效的去测试。
据我对功能逻辑性bug的分析，记住是功能逻辑性的不包括其他类型诸如UIUE上的。主要有3类：
1）大多数bug是很简单的代码错误，如果一经过大家的评审，就能发现出来；
2）一部分是业务理解错误，写的代码不符合业务需求，代码走读时也可以发现部分问题，但是不能发现全部，代码走读也可能只是对核心业务代码或接口部分进行的评审，而系统层面的需要在系统测试阶段才能发现。如果在前期保证产品，开发和测试三方对需求理解的一致性，就可以减少很多这样的bug，不是吗？
3）还有一小部分可能真的是比较难处理的bug，难复现，难调试。这部分东东，测试人员也很难评审出来。
4、最后我再补充一条：能够将自动化和手工测试很好结合起来开展工作的也是一大挑战。
我相信在很多公司，专业做自动化测试的团队对业务理解不够深刻，他们很多时候都是在研究新的技术完善测试框架，或者按照手工测试用例的优先级编写脚本，然后只是让自动化daily run。而且他们不一定知道测试哪个需求时需要自动化配合做回归测试，或者哪些内容可以提前把关键流程的用例事先实现自动化，等提测之后用来自动化smoke，哪些需求变更了又需要更新自动化。如果通过双方测试人员沟通，这种沟通的成本我觉得也不少。熟练地掌握手工测试技能并且能够自动化实现，在项目测试中很好的配合，以节省回归测试时间，这是一个挑战也是一个趋势。
相关链接：
不能成为专业软件测试人员的10大理由