编写背景：
这两天邮箱中有同行问我关于测试工具及需求变更相关的问题，这类问题听过很多、有的自己曾经遇到过，心里有些感想、同时觉的有必要总结，在此进行记录希望对大家有帮助。
同行在来信中提到的问题现象是：
问题现象1：测试完成后，出现需求变更（如：增加、修改、删除），此时的测试该如何做（如：测试执行该如何做、测试文档该如何写）？
问题现象2：开发人员和用户直接交互，出现需求变更，开发修改后没有经过QA测试，直接提交用户，导致用户发现很多bug，因此开发人员说测试组发现不了bug，要求引入自动化测试工具。
问题现象3：开发人员理解的自动化测试工具，就是能够自动发现BUG，并且能发现所有BUG的工具，让测试人员引入这类的自动化测试工具；如何让他们开发人员明白自动化测试工具的局限性，似乎不是一个简单的问题。
站在测试管理角度看上面的问题现象，我总结为三点问题：测试工作流程、测试工作技能、团队协作沟通，现在一一对这些现象进行分析和探讨。
现象1和现象2都遇到了需求变更
由于缺少需求变更处理流程，问题1的测试人员不知道该怎么办；问题2的测试人员很冤枉的背负漏出去的bug，被开发强求引入自动化测试工具。
老中医的一个观点我很认同：最终目标是要治本而不是治标；公司一位大牛的一句话我很认同：要用科学的态度看问题。
当需求发生变更后，测试该怎么办？我给的建议是：
1) 需求变更，不光牵扯到的是测试、里面还有开发和后期负责维护的相关部门；需求变更时，需求负责部门（或产品部门）、开发部门、测试部门、技术支持维护部门之间要对这个情况进行沟通协调，通过一个合适的工作流程让团队之间的工作效率和质量能有效的得到保障和提升。
2) 需求变更出现时，我认为测试能做的、应该做好的是：
a) 测试管理者对待需求变更等同于测试一个版本的流程一样，需要进行版本控制和资源协调；也要相应的对变更需求做分析（如：需求变更的影响范围、紧急程度、资源能否相应、工期的影响和风险），制定相应计划、评审相应测试用例；
b) 测试人员需要根据变更的需求以及开发设计文档，编写用例、执行测试、测试日报。。。。。等等执行相应的测试工作流程。
有的人会说，但现实情况是，有的团队就没有这么个变更处理流程、有的团队有了这个流程会要求特殊情况给予特殊处理，测试能怎么办？
1) 没有变更处理流程的，需要各个相关部门的管理者给予重视并商讨建立一个合适的，大家好才能是真的好！
2) 有了流程，需要考虑特殊情况特殊处理：
a) 例如：时间紧任务重，可否跳过QA？可以跳过QA，但QA不承担这种情况出现的质量问题，由决策者来承担。
b) 例如：时间紧任务重，QA资源紧，但必须要QA测试，测试管理者要让相关兄弟部门老大知道，在这样的情况下，QA能保障的也是必须要保障的是主要业务和功能的测试，其它的无法保障，同时要让相关兄弟部门做好这个任务的风险评估及应对配合工作。
c) 在特殊情况下的测试任务，测试有权力说出自己当前的版本质量情况及是否上线的建议。
现象2和现象3都遇到了团队协作沟通的问题
这是测试工作中最难、也是最累的；有过测试工作经验的人都有体会，测试和开发配合的好坏直接影响工作的进度、质量和团队发展。
要想解决这个问题，最终取决于这整个团队的管理者及整个团队工作的氛围。
曾记得在某一本书上看到这么一个观点：要想看一个公司管理者的能力、整个团队的管理水平及氛围；可以从问题角度去观察。
当出现问题时，整个团队是互相推卸，还是积极反馈、查找原因和解决办法；整个团队是否愿意去发现和寻找工作中的问题，能否有正确的方法去面对问题；这就要求管理者在组建和管理一个团队时，对团队成员的要求；工作流程很重要，执行工作流程的人更重要。
没有做过测试工作的人，会不知道测试工作过程中的困难和难度；没有做过开发工作的人，会不知道开发工作过程中的困难和难度；没有做过管理工作的人，会不知道管理工作过程中的困难和难度；前不久有位同事说过：有些东西你没有做过就你没有发言权。
当某些工作需要大家配合去完成时，只有足够的尊重（学会换位思考、学会沟通）、责任心才会让事情做起来比较顺利。
上面这些牵扯出另一个问题：工作技能，应该说是综合技能
做技术的，大家都知道，牛人通常不会推卸责任；牛人知道自己会哪些，不会哪些，不会瞎指挥；牛人会根据实际情况结合自身的经验给予对方建议和帮助，而不是刁难和嘲笑；牛人会用你能接受的方式让你知道自己在哪个地方出问题了。
关于现象3中的自动化测试工具的局限性，如何让开发明白，我给的建议如下：
1) 让一部分开发人员来干干测试的工作，让他做过后，就会明白了；这个方法耗费的成本代价较大，属于内耗
2) 如果公司还有其它团队，让其它团队测试工作有影响力的人给开发团队管理者进行引导
3) 收集数据，准备材料，用足够的数据（自动化测试提升了XXXX测试执行工作效率；自动化发现的bug数据；手工测试发现的bug数据XXXX等等）来说服对方，当然在说服的过程中，要得到更上一层管理者的支持和理解。
上面3点是治标不治本，最终还是要把工作流程整理顺畅，要有个合适的人在合适的位置上选择一堆合适的人，然后带这堆合适的人一起做事。
在我测试工作的7个年头里，经过在不同公司和不同团队配合做事后，让我感触最深的是：测试工作要做好很不容易。