测试工程师具备了分析能力，测试就会做到有的放矢。如果什么都是拍脑袋，临时决定，这样做缺乏全局观，看到的是部分，而不是整体。得到的结果也是部分，不是整体。

　　蔡：那么，具体如何提高分析能力呢？

　　邰：你知道，分析能力不是知识，而是一种skill（技能）。知识的提高可以通过看书、参加培训来实现，技能的提高只能靠多实践。我建议大家多拿一些需求来练习。例如，如果是学习Model Based Testing（基于模型的测试），就拿需求来多练习建模，甚至针对同一个需求用多种模型建模，去比较这之间的差异。如果可能的话，多个人一起学习，可以拿自己的model和别人的做比较，当然，如果能得到有经验的人从旁指点就更好了。这样的练习做多了，就会形成自己的分析型思维。

　　旁观者说：学习既要个人独自的努力，也要公开讨论，二者各有好处。

　　招聘测试工程师时的要求

　　蔡：你负责招聘的时候，对于测试工程师有什么要求？

　　邰：回想过去招聘的时候，我觉得有的时候没有招对人。如果我现在做招聘的话，我会重点考察面试者是否具备测试人员必备的一些测试技能。

　　比如，给面试者一个小程序去测试，或者给他一个小游戏去玩，或者问他一些问题，观察他的反应，这个过程可以体现面试者的测试思维。再比如，观察面试者的问问题的能力、逻辑思考的能力、逆向思考的能力、观察是否细致等。

　　还可以给面试者一个有些挑战性的任务，观察候选人的学习能力、分析能力、解决问题的能力，以及是否有面对挑战的激情。如果一遇到问题，就不知道怎么做，或者没有兴趣去解决问题，原地待命，等待领导，这样的人不适合做测试。

　　有一点需要分清楚的是，有测试经验并不等于具备测试思维，因为二者是两回事。

　　旁观者说：我在面试中比较看重发散思维能力。

　　在面试中，我不会问“什么是等价类”之类的直白的理论问题，因为没有意义。候选人即使不会，也会很快学会。

　　敏捷让测试如鱼得水

　　蔡：现在敏捷已经流行开来，很多公司采用了这种软件研发方法。你对软件测试如何适应敏捷有什么建议？

　　邰：对于这个问题，我觉得可能换一种问法更好，并不是“软件测试如何适应敏捷”，而是“软件测试如何适应瀑布模型的？”

　　我在了解了敏捷之后，觉得这才是软件测试应该处于其中的开发模式。敏捷中的很多理念把测试的本质充分发挥出来。

　　“个体和交互胜过流程和工具”强调的是以人为中心，而不是以流程和工具为中心。测试中以人为中心，强调的就是通过个人技能的发挥、通过与其他角色有效的沟通获得有价值的信息，做高效的测试，这比一味地遵守流程和规范重要得多。

　　“可以工作的软件胜过面面俱到的文档”，这当然是测试想要做到的。以前测试没有办法在项目早期就拿到可以工作的软件开展测试，敏捷以后，测试不用等那么久了，我们可以尽早开展测试了。

　　“与客户合作胜过合同谈判”，这也是测试人员一直希望做到的。以前我们想找到客户，想了解客户到底在意哪些方面，我们希望站在客户角度测试，可是很难做到，测试和客户的距离太远，我们只能把自己假象成客户去测试。现在客户和我们紧密合作，我们有很多机会和客户接触，了解客户真实的需求，我们可以开展更有针对性的测试。

　　“响应变化胜过遵循计划”，这也是测试提倡的。测试要基于风险，而风险是一直在变化的，我们必须拥抱变化、响应变化，而不是只知道遵循一个事先制订好的测试计划，我们的被测对象一直处于变化中，我们要找的bug也不是按照计划出现的，我们必须基于风险、调整测试，准备随时、随地发现各种类型的bug。

　　在我看来，敏捷让软件测试如鱼得水。所以，倒是以前在瀑布模型的时候测试需要去“适应”。

　　旁观者说：敏捷的好处前面邰晓梅已经说得比较细了，我这里再来补充几点个人的认知，尝试让读者朋友们得到一个全面的认识。

　　（1）敏捷中仍然需要编写和保留一定的重要的文档，例如主要功能的设计。有的团队在实施敏捷的时候打着敏捷的旗号不写文档了，项目信息都存在组员的脑袋里。这样做的风险是，每个人对于应该做成什么样子可能有不同的理解，而且当有员工流动的时候会有比较大的挑战。

　　（2）客户的参与在国内是双刃剑。有的客户做事并不专业，认为自己是甲方就随便更改需求，直接给研发团队下指令，导致研发团队疲于奔命。最好是既让客户参与，又让客户与研发团队保持适当距离，避免干扰。

　　（3）是响应变化，还是遵循计划，需要单独分析，看优先级。