敏捷的质量之觞

  在公司做敏捷快三年，每每在关键时候遇到高风险影响出货的危急关头，都无一例外的会把矛头指向质量。

  按照业界的常用规范，以及我们公司的标准，看似每个冲刺都执行的很漂亮，但是你放眼整个release，把冲刺当作一个点，而非一个时间段，不难发现整个过程是扭曲的，有很多坑没法填的。

  一个公司在导入流程的时候会有大量的培训予以洗脑。这一点和行销类似。一个销售在卖产品的时候，她只会宣称自己产品的好而不会强调自己产品的缺点和短板。美其名曰“瑕不掩瑜”；最主要的就是出了问题归售后管。而公司也是一样，一旦引入敏捷就拼命的宣扬其好处然后对于敏捷中的问题不予以强调。我后来也回过味了。其实大家都是新手，其实他们也没真正在实践中碰到过多少问题，而我坚信国内市面上那些鼓吹敏捷并到处作培训的人自己本身有多少实践经验了？敏捷这个玩意真的就是实践出真知，每个团队都有不同的玩法，因为她没什么理论基础也没什么特别的方法学。完全就是前人的经验集合。而前人的经验肯定不会完全适用于你的项目，你还得裁剪还得再自己琢磨。所以，敏捷一定得强调人强调回顾。我们反过来问，对于敏捷中提出的那些标准，其他的流程没有吗？其实，大部分的流程如MSF或者RUP，都无一例外的都敏捷中提出的标准都有所涵盖，而且有着很明确的推荐实施方法。而这些标准中无一例外的都在强调着质量。

  质量如何保证呢？一个产品的研发会经历很长一段时间，短则数月，长则数年，虽然我们会把它化为更小一些的阶段性成果。敏捷的观念是每个冲刺都需要保证实现定义的故事被高质量的完成。很好，每个冲刺都完成了。那么产品呢？有没有产品维度的质量保证呢？ 

  在目前，我们公司对CASE的维护主要是以冲刺为时间单位，以故事为驱动。每一个故事背后都对应着大量的CASE和数据。那么对于一直往前不用回头的项目来说自然没有问题，但是对于敏捷一直强调的，变化不断的情况该怎么办呢？通常情况下，我们会把改变分作两类，一个是大改动，一个是小改动。小改动的话，我们一般不另起故事，而是大家抽空做掉；而大的改动则会重新做一个故事出来，完全站在用户的立场去描述改动后的状况，那么此时的针对这些变动而来的CASE是对应在这个故事上的，那么后人在看到冲刺中所作的故事的CASE时，其实是没有看到产品的真实状况。这就是说，如果一个后来者想要了解一个产品的测试CASE需要通读所有的冲刺中的故事形成自己的脉络。而这个脉络形成与大脑，不知道是不是也终至于大脑，这样重复的活动会一次又一次的去作？这就是说其实我们考虑一个测试工作的话，是说测试是在测冲刺而非产品。这样的结果就是几乎无人可以进行全面的交接工作。这也就是敏捷非常强调团队的稳定性和对产品的高熟悉程度，但是我觉得这些都太理想了，这也就意味着能做敏捷的都是大公司了。

  另外一个严重的问题就是使用敏捷的公司没有自动化测试工具。这点其实也很可怕。按照敏捷的要求，测试可以不要CASE，时间不允许的时候可以先按照理解来执行测试，有空再补。我的观念是想保证敏捷中的质量就必须大范围的进行自动化测试。测试人员的工作就是写自动化测试脚本，和开发人员一样，只是代码的立场和角度不同罢了。一旦发生需要变动则相应的调整测试代码。这就是说没有传统的 CASE了，测试代码就是CASE；是不是和敏捷中常说的抛弃设计以代码为中心的说法很类似？只有这样，我们才可以让测试的维护和产品的维护保持同步进化，我们可以在任意时间点确认整个产品的质量是没有衰退的。因为我们不是在输出冲刺而是在输出产品。 

  这些都是牢骚之言，对于一个敏捷团队来说，真正的去理解质量是TQM是很重要的，让QA从头开始介入行驶QA权利是必须的工作。而法无定法，我们需要QA人员去创新，结合团队的实际情况以及企业的环境，来决定如何从头至尾的保证产品的质量，并且在一开始就需要针对此形成文档化的质量管理方案并严格执行，最终形成产品线或者更高一层的组织级别的质量计划。在这点上，创新很重要。因为敏捷是一个弱计划的流程，会在实际过程中发生很多偏差，这些偏差是对整个团队的考验，而任何的改动，测试人员总是最后一个环节，他们会经受巨大的进度压力和信任危机。

  有了这些压力才是一个合格的敏捷测试人员成长的动力。