很多刚刚步入GJB5000A门槛的组织，面临的一个巨大的问题就是软件工程的能力薄弱，尤其是测试能力。
在一些领导的眼中，测试工作是一种辅助工作，所以测试人员没有开发人员那样重要（仅仅是二者的相对值，不要自取其辱地和系统人员比），测试工作没有几人愿意承担；领导也不愿意在测试工具上加大投入。
所以，我们更应当考虑测试的敏捷性，构建敏捷的测试过程：用尽量少的人，办尽量多的事；投入的工作量不多，收到的效果不差。
可是，天上不会掉馅饼。要实现这样的敏捷测试，就要克服以下的困难：
1. 没有一个成熟的测试过程
就像练功的三层境界——守、破、离——那样，一个过程也需要从僵化吸收，到熟练应用，再到灵活使用，这样子逐渐演变过来。敏捷的前提是已经有了一个成熟的过程。这样，我们就会很清楚过程中哪些是不能裁剪的，不能打折扣的，哪些可以裁剪的，可以灵活处理的，又不影响效果的。这样的敏捷是有效的，结果是有预期的。没有一个成熟的测试过程就高谈阔论过程的敏捷，就好像把敏捷构建在一个空中楼阁之上。
不会走，就想跑，非得摔跤不可。
而要建立一个成熟的测试过程，最快的方法就是从别人那里学习先进经验，在本地试点改进。
2. 测试过程并不能更改需求
在组织的文化当中，一直认为测试只是一种检测缺陷的手段，从来没有把测试作为提高软件质量的一种手段。
好的测试，不仅能够找出软件中存在的缺陷，还能够根据这些缺陷的数据分析，给出改进软件设计的建议，从根本上提高软件的质量。
这就要求组织从文化上、制度上重视测试，让测试人员认识到测试和开发同样重要，他们才会积极地参与到敏捷测试过程的构建中来。
3. 没有定义测试质量
每一项活动都应有一个标准来衡量它完成的质量。测试活动也是一样。如果没有定义如何衡量一个测试活动的质量，就很难对它进行控制，也不知道如何对它进行优化。
4. 测试过程不是目标驱动
实现敏捷的主要原则之一是每个人都要了解目标。只有每个人都了解项目或过程的目标，并主动地为这一目标而努力，敏捷才有可能实现。
要让测试过程变得敏捷，就要建立敏捷测试过程的目标，并让每个参与敏捷测试的人知晓，并为之而努力。
5. 没有一套灵活有效的沟通体系
实现敏捷还要有一个灵活而高效的沟通渠道。在测试人员与测试人员之间、与开发人员之间、与用户之间以及与管理部门之间，要建立起一套高效灵活的沟通渠道，这样需求能够很快达成一致理解、测试问题能够得到快速响应、问题的解决方案也能快速得到确认。
6. 测试人员不如开发人员受重视
如果测试人员一直得不到重视，他的主观能动性就会受到影响，他的测试还能敏捷起来吗？
7. 没有足够的资源投入
测试的敏捷不仅需要测试人员积极主动地参与，同时也需要有足够的资源投入。比如：自动化测试工具。没有称手好用的工具，只靠人力去填补工具的缺失，测试的效率又怎能上得去？
8. 没有一个高效的敏捷测试领导小组
如果组织想要构建一个敏捷的测试过程，没有一个强有力的高效的领导小组，是不可能实现的。必须得有领导认识到构建敏捷测试的重要性和意义，并且有开发代表和用户代表参与，这个敏捷测试领导小组才能发挥作用。
那么问题来了，那些测试能力较弱的组织，领导对测试都不够重视，还会重视测试的敏捷性吗？
这是一个死循环？好像。
这正是：
能力不足唤敏捷，谁知敏捷要求多
八道难关横面前，领导给力能解锁
参考书目：《软件测试的有效方法》
联系客服
