软件测试工程师的职责(2)

　　测试质疑代码时，就是带来价值。

　　When a tester finds even a single defect, she is adding value by exposing the hole in the product. The product owner may delay or defer the fix for it for product delivery timelines, but they cannot ignore the existence of a defect in the product.

　　测试发现BUG时，就是带来价值。

　　测试不应该只把眼睛放在具体的产品上，就应该考虑整个软件开发过程中每个环节上去，看看是不是能发现BUG。只要能带来价值都是好事情。

　　个人观点

　　测试不仅需要测试产品，而且需要测试需求、设计等各个环节以及过程本身。关注如何做对的事情，减少不必要浪费。

　　我们都知道一个观点，越早发现BUG，修改的代价会越低。测试就需要尽早参与到开发过程的每一个环节中去。

　　我不知道目前国内公司的普遍情况，测试能做些什么事情，但我知道的确有些“大”公司，流程分得较细，传统的测试加入较晚，参与的阶段有限，比如，需求文档创建时的Review就不会参与;限制传统测试人员做UAT的事情，因为还有专人在专门的UAT阶段做UAT。 说句题外话，真不建议应届生加入这种公司，过程过僵化，测试能接触得东西过少，能学习到就过少。

　　这里想说得是，如果流程分得细，阶段明显，代价会更大，需要招更多的人，知识传递更费时费事;需求阶段，设计阶段Review的人，如果没有带着一些测试思维来做Review，效果很可能有些折扣。就个人的眼光看来，还不如直接让测试更多地更早地参与项目，为整个过程服务，不仅仅为产品测试服务。对公司，减少了消耗，对员工，增强了技能，开拓了道路。

　　敏捷倡导跨功能的团队，各种角色的成员尽量都坐在一块。其目的之一，使各个角色更好的协作，也使各个角色间的界线有些“模糊”，比如，现在蛮出名的DevOps角色，就是开发和运维的混合体。我目前期待能够出一个测试和分析师(BA)或者领域专家的混合体，一个能分析、判断业务，能和商务沟通，能做用户代表，能测试、能检查设计和产品，保持测试思维，持续关注价值的角色。姑且先东施效颦，仿造一个合体词出来，TestAnal或者Testlyst。

原文转自：http://blog.csdn.net/o2o_o2o/article/details/9208623