今天工作中碰见一件事情，让所有人都觉得有点郁闷。
我们产品是一个底层的安装框架，对上层要支持平台软件，再上层还要支持产品软件。每个都是独立开发，每个产品都定时在货架服务器上上传新的相对稳定的版本，来支撑其他子域的测试和验证，整大产品的主要客户是电信运行商，规模比较的大。
我们的产品应为涉及到很多个平台（linux，solaris，windows）且每种系统上还有多种不同特征的版本（单机双机多机....），一个正常的转测试流程下来，涉及到的测试场景有10多种，平均每个测试人员要分配2-3个场景，而且不包含各种专项测试，任务量比较繁重。
一般情况的转测试，都只使用平台软件来配合，不会涉及到产品软件，偶尔零星的也会使用产品包，如果涉及到产品包，我们就称之为“联调”。进这个项目三个月以来，只见过几次联调，每次都是那个几个老员工来做。
每次转测试的各种包，都是开发的CMO从货架拿版本然后再转到测试，经由测试经理和TSE制定好测试策略以后转发给测试员测试，整个流程测试人员基本不会接触到货架，虽然一开始测试经理一直在强调每个测试员都需要熟悉怎么从货架获取最新的版本，但是一直都没有特别的测试要求从货架取版本，再加上测试任务繁重，新进的测试人员基本都不知道如何从货架取其它域的软件包。
这次的转测试，是星期六早上，测试员需要花大约一天的时间来准备测试环境，迭代开发的原因，转测试流程非常紧凑。周一晨会，测试经理宣布本次测试的所有场景都需要联调，所有测试员都要从货架上获取版本。几经周折以后才发现，包括测试经理，TSE在内的10个人，只有3个会从货架取平台包，只有一个会取产品包。于是所有的测试进度都停滞，等待产品包。偏偏不巧，产品的货架包又存在不确定因素，需要和产品域的人沟通，而产品域的联系人正巧又在开会，于是整个测试进度从上午到晚上下班，一直停滞。
导致这个个时间的根本原因就是技能储备不充分，总结一下自己对这个事件的看法以及解决办法：
1、对于测试策略传达不到位；
测试经理在转测试之后的第二天晨会才开始说明本次测试的策略，及特别注意事项，这忽略了测试人员应对新的测试需求的学习期。
再转测试之前的一天或者转测试后的第一个例会上，测试经理应该明确的指出本次测试涉及到的场景，功能点，所需要的配套软件，任务分配，测试周期，测试注重点。需要注意新的测试需求是否每个测试员都能理解和操作，虽然此类文档在服务器上都有，但是每个人的理解都是不一样的，是需要测试经理做说明解释。如果有三成以上的测试员对新需求不理解，需要预留时间，并组织专项培训。确保每个测试员都能独立动手操作。
2、技能储备不即时，不充分；
之前的多轮转测试中，没有特别检验过一些必备的技能，是否每个测试员都具备。
在测试的过程中对于测试员技能的储备，是一项非常重要的工作，不能总之把希望寄托在测试员本身，必须要有一些方法来强制性的让测试员对测试过程中需要用到的测试技能充分理解和运用，比如定期的组织测试员在一起讨论，实现将测试所需技能按照优先级罗列，要求每个员工说出自己对技能的理解和运用。只有这样才能确保每个测试员都把基本的必备技能吃透，而不是莫林两可。
3、测试员对于学习缺乏主动性，存在依赖思想
测试员总是这么想：我只是个测试员，按照测试经理提出的要求做事情就是，不需要特别的去学习，就算在测试过程中遇到不懂的事情，还是可以找老员工帮忙解决。我在这里学到的业务知识，到下一个项目就完全没用了，所以没必要那么认真。
如果存在这种思想，那测试员就一直是测试员，不会有提升。不可能一辈子只做一个项目，所以总会有心的开始，业务知识带不走，但是学习知识的方式方法却可以带走。只有经历这个学习业务的过程，你才能发现自己适合什么样的学习方式。如果养成了一个良好的学习习惯，无论做什么项目，你都会是优秀的。还有要相信一个道理，除了自己以外谁都靠不住，因为这个世界，你能控制的就只有你自己。
以上言论属个人想法，仅供参考。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/