聊聊敏捷测试中，开发测试的磨合问题

lsekfe

最近负责了一个技术中台敏捷项目，对于我个人这倒不是什么新鲜事，但对于目前的团队，这种测试项目无论对于研发还是测试都还处于前期，尝试和磨合阶段。
　　今天就来分享下，在这个过程当中，遇到的问题，与目前的解决方案。
　　1 问题一：什么时候出测试方案，要不要评审？
　　第一个迭代还没开始，无论是需求还是技术方案都没理清楚的情况下，需求和研发组就一直向测试团队要测试方案，这种情况下，当然无法给出测试方案，如果要给也是在目前了解的信息的情况下，给出大概的思路，其实称不上是方案。
　　测试方案一定是在需求明确，技术方案明确的前提下再给出才有意义。
　　2 问题二：模拟器的封装谁来编写？
　　我记得第一次跟研发架构师沟通测试方法的时候，我提到这块的测试需要开发一个模拟器。当时架构师就说，这个应该由测试人员来开发，其实不然，我们聊聊看。
　　研发的技术实现是一个SDK，如果要测试这个SDK，就需要调用里面的方法，所以需要封装一层模拟器，模拟器调用SDK里面的方法来进行测试。
　　这种情况下，有两种测试方法。
　　第一种，测试人员直接对SDK进行测试，包括读懂代码逻辑，编写模拟器，实施测试，成本就是对测试人员代码能力要求很高，可测性和测试可维护性成本很大。
　　第二种，由专门的同学负责开发模拟器，然后真正的测试是对模拟器的测试。模拟器可以是API服务，这样的话就将SDK的测试转变为API的测试，可测性和测试维护成本就小很多了。
　　第二种方法是最合理的，但同时带来一个问题：谁来开发模拟器，测试同学还是研发同学？
　　在思考这个问题的时候，大家普遍存在的一个误区就是：与测试有关，就一定由测试同学来做。
　　其实不然，测试是存在整个研发流程的，从需求的那一刻开始，测试就已经在进行，比如，需求设计需要考虑用户实际体验，这本身就是用户体验测试。
　　再比如，研发的单元测试、内部联调测试，这些都是测试的范畴。
　　因此，这件事情，谁来做，关键因素是谁来做能够最大化提升项目交付效率。
　　开发模拟器，需要直接调用内置方法，需要代码维度有足够的了解，显然研发来做比测试直接来做效率更高，想想为什么单元测试是研发来承接的，道理是一样的。
　　当然，对于模拟器，测试同学也需要做一些事情，那就是模拟器案例的编写，因为，开发模拟器的前提是你得知道模拟器实现的功能是什么，模拟器最终是提供给测试同学使用的，测试同学通过模拟器来测试软件，因此，测试同学设计好案例（相当于需求），开发同学根据案例（需求）开发模拟器，这才是最高效的合作模式。
　　3 当然，整个过程还需要考虑的问题还有很多
　　比如如何管理测试版本？
　　测试同学需要清晰的知道目前的测试版本是什么，测试的开展一定是在特定的版本之上进行的，这样才能方便的追踪问题，这也就是说研发一定需要交付给测试一个明确的可测版本，这是测试的开始条件。其次，bug修复需要有单独的版本追加部署。
　　再比如测试环境如何保证独立性？这里其实包含两部分考虑。
　　第一个考虑点是测试研发环境需要分别独立，测试环境一旦部署，就不允许有任何修改，研发的开发工作在研发环境进行，这样才能做到互不干扰，开发测试并行。
　　第二个考虑点是假如有bug需求修复，那么就需要研发在开发环境调试通过，然后发布一个新的版本，完成新的测试环境部署，测试同学在此基础上开展回归测试，bug修复不允许在测试环境直接修改调试。
　　实际测试过程中，会出现研发会有意无意修改测试环境代码，虽然测试环境调试通过，但是代码没有进行版本变更，可能导致最终的测试版本与实际提交的版本不一致，进而引发测试[url=]漏洞[/url]。
　　再比如案例走查后，测试人员测试期间，如果存在功能变更，如何周知测试同学？
　　敏捷测试，由于研发测试耦合较深，变化很快，如果不及时周知变化，轻则测试会做很多无用功，重则遗漏测试点。
　　如果同步太多繁琐，又会降低敏捷的效果，因此，需要找到一个合作的舒适区。
　　这些问题，都需要在磨合的过程中，逐渐建立起来一套机制，去约束研发测试的整个过程，以达到最大化提升项目交付效率的目的。
　　技术精进是一场修行，相信自己和时间力量。