你是一名专业的测试人员吗？

　　如果你看到这篇文章了，你就有机会成为专业的了！

　　我写这篇文章并不是因为这个，其他无数的测试人员有比我更多的好东西拿来分享。总体而言，我的意思是在空闲时间阅读其他测试相关文章来提高自己的测试技能时，你也将是有志成为专业测试人员中的一分子。

　　寻找最佳理由

　　上周我在LinkedIn上看到有人讨论“为什么测试不是一份职业”，有很多答复包括说“因为大学没有专业授教”，但都是说“因为它是新兴的，人们并没有专业的进行学习”。但我没有找到有人反驳这个观点的人并说“因为大多数人工作的方式就不是专业的，才被觉得测试不是一份职业”。

　　我猜大家都注意到了给我们的责备而忙于自怜和抱怨受到的不公平。

　　寻找答案

　　坦白的讲，不管在哪我们不被当成专业人士都是因为我们并没有优先地专业化的开展工作。

　　基于我有限的工作经历，不管什么地方认真对待工作并尝试改进而给组织带来的价值的测试人员都会被尊重，并且会给予高度的评价和感谢。

　　现在切入正题，不能成为专业测试人员的10大理由：

　　1、你认为测试并不是一份技术性的职业，所以并不去尝试学习理解产品的编码

　　如果你从事的是软件开发，至少会理解一些软件工程的知识。而作为测试人员，你应该能够读懂代码来分析产品，来理解代码的变更和修复将会如何引入其他的bug.黑盒vs白盒的日子应该结束了。

　　如果你不想这样，即使不用写任何代码依然可以从事该工作。但是如果你不去读代码，将会失去对整个测试流程很重要的一项投入。

　　2、只有当开发人员告知开始测试时才真正介入到整个流程中

　　大家如实的回答，在整个开发流程中何时开展测试的？

　　理论上我们想在需求收集分析阶段就介入，和其他成员一起完成余下的，事实上我们很难投入进去，只有当开发人员想尽快得到反馈首次提交代码交付给我们时才能介入。

　　为什么要这样持续下去？大多数测试人员会说这种测试工作是开发流程中的最后一环，当其他人忙于计划时我们总是忙于测试。

　　但是实际上，如果不能每天抽两小时做测试设计就意味着你在管理时间上很差劲。而且还意味着，你不想提早介入到开发流程中的唯一原因是没有优先处理，或者换句话根本不想这么做。

　　3、只有在技术支持的同事要求重现bug时才与客户之间交流

　　测试人员一部分工作职责就是基于各种用户使用场景进行测试，一旦产品发布之后基于场景来寻找bug尤为重要。

　　但事实上（这里应该指的是外包项目中），在整个开发流程中你只是代表了客户而不是用户，根据客户的工作行为来计划测试及搭建测试环境，只是被期望基于他们的需求和限制来提供功能反馈。

　　如果真是这种情况，不了解真实的用户如何代表用户模拟他们的行为呢？最后一次访问用户如何使用产品是什么时候？工作中你能真正考虑到他们如何使用产品和工作环境有哪些限制吗？我猜答案一定是NO！

　　去拜访一些用户直到你理解他们，才不会一直做这样差劲的工作。

　　4、只有在处理人寿保险时才进行风险管理

　　对于测试有一个简单的真理，也许是最微不足道的：测试人员没有足够的时间验证一切。这时，基本的风险管理派上用场了，帮助我们区分工作的优先级，哪些需要测试，哪些优先测试，可以假定哪些是基于其他测试结果上工作的。

　　但是如我所说，这只是风险管理基本的一面，更高级的是在分析跟测试压根一点关联都没有时候可以提供更大价值。

　　所有测试人员都知道产品中风险更大的区域是哪里，哪里有更多的bug，团队因为什么不定期和无计划的事务被推迟的。

　　作为测试人员我们应该意识这些区域并在项目不同的阶段实时提醒团队。这样，我们也能决定是否使用产品其他模块开发这些功能，或者考虑到这些意想不到的问题迟早都会出现，如果允许的话是否可以花更多的时间来保持系统的稳定。

　　你应该尽力尽早暴露这些影响产品的问题，不管是已知的还是潜在的，帮助团队设定靠谱的目标，在时间和预算上达成目标。

　　5、你没有任何计划来提高自己测试工作的价值

　　测试职业在许多方面都是未知的领域，有很多途径带入到测试行业，一旦进入到测试行业中，就有各种途径来改进测试专业技能。大部分测试技能提升来自于个人，而且将会由测试人员个人能力，当前工作环境的需要和限制，还有就是当前能获取的信息来源等因素决定的。

　　总之，并没有唯一的途径把自己培养成一名专业的测试人员，而且并不容易，成效并不快。所以除非你决定想真正改进开发流程，并且知道如何达到这些目的后才能够真正提高测试技能和提高能够贡献给团队的价值。

　　如何达成呢？

　　开始列出作为测试人员的强项和弱项，想想哪些方面你想改善，最终寻找可取的方法。有一件事很确定，如果你不把握机会或者跟别的测试人员的职业发展牵着一起，将永远不可能得到提高。

　　6、我们认为测试工作就是设计和运行预先定义好的测试用例

　　其实除了运行测试用例之外，还有更多的内容：

　　- 对产品设计上提供反馈；

　　- 分析当前项目计划的风险；

　　- 在不同的开发阶段提供非正式的反馈；

　　- 开发自动化框架，能帮助开发人员维持他们所开发的产品的稳定性；

　　- 运行脚本或用例，但不单单是之前预先设计好的；

　　- 分析测试结果以及能获取的所有信息，帮助我们了解产品的最新进展状况；

　　- 在流程中持续反馈

　　而且我们可以照这些步骤持续开展。

　　总之，如果只是单纯的运行用例并设置为PASS OR FAIL，那价值远远没有实现。

　　7、自动化是一门高级学问，测试项目能在以后空闲时间里开展

　　请不要想出一大堆借口解释为什么不做自动化！

　　从另一个角度讲，这是一些测试人员技术弱点的另一面。

　　自动化不是灵丹妙药，并不能处理测试人员遇到的所有问题，但是通过使用脚本或工具仍然能够代替我们做一些重复的劳动，更高效，更省时。

　　问题是，一些测试人员到这里仍然感觉不够有技术含量，所以他们并不选择通过自动化或脚本改进测试。某种意义上讲，就好比使用钻木取火而拒绝用打火机并一边说这种方式很容易。

　　8、大多数时候非常自我自负的做测试

　　一个好的测试人员应该谦卑。我们需要知道如何提供反馈，更重要的是如何从其他组员或同行那获得反馈。

　　如果其他成员特别是开发人员对测试工作提供一些未经请求的反馈，或者他们查出bug遗漏或测试没有执行后，很多测试人员感到很沮丧。其实每次都有很好的理由来解释漏测，只需要冷静下来分享下这些信息，但是很多测试人员认为这是对工作失职的人身攻击，并且反驳说一些难听的话。

　　同时，我们需要知道如何提交bug，并为团队提供消极的反馈，并且需要知道如何从同行那获得建设性的批评。

　　没人期望你是完美的。但是他们期望你能认真对待失误并且同时从获得的反馈中学到经验教训。

　　9、并没有跟进需要改进提升的技能或领域

　　之前我其中一个最好的经理经常谈论我们个人的“虚拟工具箱”，好比我们所携带的技能在需要的时候随时可以使用。

　　在你的工具箱里都有哪些？

　　哪些工具需要改进或更新了？

　　哪些是你需要的，哪些是下一步想要获得的？

　　不容置疑，测试像是一门手艺，没有合适的工具不能创造需要的产品。

　　10、你的职业发展生涯就是成为管理人员或改行

　　有些人转行是因为他们觉得做测试是种很好的途径转做开发，还有部分人根本不知道测试是干什么的，甚至是因为觉得整体玩弄这些程序很好玩。毕竟，也难不到哪里去。

　　一部分人最终成了很棒的测试人员，但是多数人最后失意收场，度日如年的盼着啥时候能结束测试生涯，可以做自己想做的工作，而另外的人并不欣赏测试所带来的挑战，他们觉得唯一获得进步的就是做管理。

　　没错，做管理的确也有挑战和收获。但是不做管理也是要克服无数的问题，这些也许能给予你更大的挑战和收获（绝对还没那么头疼）。

　　我的观点是，如果你一直在想做其他的而不能关注于做一名更好的测试人员，根本不可能做的更专业。所以想想是否入对了行或者可能应该简单地摸索点别的。

　　想成为专业？首先作一个专业的测试！

　　总结上面10点，贯穿始终的是如何改变我们对测试的认知。

　　第一步就是把测试当成你的职业！

　　当我们做到了第一步，第二步就是看看哪些我们遗漏了，哪些我们需要加强，我们要怎么开展工作以及如何与同事及客户处理好关系，以及为了提高我们的价值现在能做什么。

　　第三步是我们应该未雨绸缪，并且意识到作为一种职业在变成大师或专家之前有很多东西需要学习。

　　最重要的是要意识到这种改变要发自肺腑有实际行动，而不是从一些神赐予的法令而来，或者邮件所署名字旁边的标题来证明。

版权声明：本文出自 zzzmmmkkk 的51Testing软件测试博客：http://www.51testing.com/?258885

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。