在软件研发中，有一种思想叫TDD，即测试驱动开发，TDD是敏捷方法中的一项核心实践，其原理是在开发功能代码之前，先编写单元测试用例代码，对要编写的函数或类明确测试方法后，再进行设计与编码。
本篇不是讲如何来实践TDD，而是利用这种思想来推进项目的进度。大部分人可能都有这样的感受“别人催着自己的工作往前赶，心里贼反感”，“而自己催着别人往前赶，心里只有快感”。
在大部分项目都在走敏捷模式的情况下，项目经理已经被弱化，而产品经理更多关注设计、客户，使项目团队经常出现一团散沙的情况。作为下游的测试团队就贼难受，上游的设计、开发掉了链子，如延期，在时间截点已被卡死的情况下，测试团队很难顺利完成项目测试并交付。
项目没有顺利交付，不管什么原因，板子必将指向测试。所以，此时活用“TDD”显得很有必要，精髓是“驱动”。而测试要驱动设计、开发，根据小酋的实践，需要从计划、需求、用例、转测四点着手。
计划
不管项目如何变化，都需要一个大家共同确定的计划。不用出一个非常详细的计划，可以是一个一个的时间节点，比如A模块什么时候完成设计，什么时候交付测试，什么时候完成测试。
当这些节点确定的情况下，我们才能去驱动项目进度。不论是产品经理做设计变更，还是开发人员落地搬砖，测试才有一个底，应对其中的变化，是力争调整计划，还是协调加大测试资源投入，亦或是调整测试策略，才能做到有理有据，有条不紊。
否则只有截点的情况下，可能产品经理说对不起，客户有了新的需求，设计要多花点时间，大家后面紧一紧；开发人员说对不起，这个技术超出了预期，或者又加了新需求，那只有辛苦测试后面加加班；最后轮到测试，截点在望，只能边吐槽边熬夜，搞得身心憔悴。
需求
需求，大家都知道非常重要，但问题常常还是出在上面。比如，大家理解不一致，场景、业务考虑不全，脱离实际无法实现等。
作为测试，我们必须认真啃需求，产品经理知道的，我们一定要知道，而产品经理不知道的，我们还得指出来，做好跟踪，确认解决。如果判断极可能出现理解偏差的地方，要与产品经理确认，理解一致后把信息同步给对应的开发人员。核心要点：尽可能早地发现需求中的问题，并跟踪、确认解决，减少开发歧义和后期出现的设计缺陷。
用例
用例越快完成越好，越早完成评审越好。
要推动项目进度，测试用例的设计也要提效。在敏捷项目中，我不倡导教条主义，即一定要按照XXX标准模板去编写，而应该积极探索更加快捷的方式，如测试思维导图，测试点列表等。用例，我们应花精力在设计思想，业务逻辑上，而不应该过分追求形式，除非时间允许，或者有其它需要（如后续作为客户验收用例）。
用例出来后，要做评审。可以根据版本大小，确定参与者的范围，但一定要有产品经理。评审通过后的用例，我们可以分享给开发人员，这也是开发人员可以查漏补缺，消除需求理解偏差的重要途径之一。
转测
要想测试顺利，转测（即开发提测）质量也关键。
测试最不能忍受的情况，可能就有：提测后，明显的功能都出错。如转测登录模块，输入账号、密码，点击登录报错了！
那怎么能保证转测质量呢？这里有三个实践：
1、提高开发人员的质量意识
这可能很难做到，所以退而求次，提高开发leader（或者主导开发人员）的质量意识，只有开发leader去强调、去推动，转测质量才有明显的改善。
我们要做的就是，平时和开发leader搞好关系，多交流项目中的看法，潜移默化中达成对软件质量的统一看法。
2、开发自测
我们可以寻求上面的支持，引入开发自测的环节。在开发提测前，我们可以提供自测用例，这些用例应尽可能精简，能覆盖提测内容的主要功能，如登录模块“输入账号、密码登录成功”。
3、冒烟测试
同样，我们为了保证转测质量，引入冒烟测试环节。即开发转测后，只有当我们把主干测试用例（与上面开发自测用例同理）通过后，才进一步做后续的系统测试。否则，有主干用例执行失败，就视为冒烟测试失败，打回开发责令其整改后再提测。
通过上述四个方面，我们基本上就能很好地驱动项目了，但实际情况远不如文字这么简单、明了。具体执行效果还得依赖于我们的沟通能力，协作能力，以及人格魅力；不管是能力、还是魅力，都建立在我们不断总结、思考、学习的基础上。
-- End --
文末寄语：一生平淡少曲折的人，难以成“大器”。期盼着“运气”的施舍垂青的人，更是命运的奴隶。只有勇踏坎坷的人，才能真正驽驾人生。