同行在来信中提到的问题现象是：

　　问题现象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都遇到了团队协作沟通的问题。

　　这是测试工作中最难、也是最累的；有过测试工作经验的人都有体会，测试和开发配合的好坏直接影响工作的进度、质量和团队发展。

　　要想解决这个问题，最终取决于这整个团队的管理者及整个团队工作的氛围。