我们定位这样一个角色：你是一名功能测试人员，在项目组负责某个子系统（或者说后台服务）的一个版本测试，该版本新增了功能，又修改了原有bug。没有规范的文档，你将如何测试？
　　有人是如此测试的：咨询一下开发修改了哪些功能，拿到手上开始根据开发提供的思路跑流程，测试通过，上生产。结果生产上造成很严重的问题，而这个问题产生的根源是开发改动了关联部分公共方法。同时作为测试，根本没有考虑到该版本的功能关联了哪些业务场景，所以也无法发现该问题。项目经理问责测试：作为对该系统测试了两年多的你，为何这么简单的问题都发现不了？测试用例写得这么粗糙。
　　这是我眼前的真实存在的一幕。我无法端坐在旁边，看着可怜的测试人员在无力解释，“我也发现了很多问题，你怎么就看不到？”“我们联调协调的很辛苦……”。我很想知道问题在何处？
　　思考良久，我知道某个人肯定有问题，但又不全是某一个人的问题。需求没有文档，开发没有设计思路，测试设计缺失，遗漏该功能的测试，最终问题在生产上“华丽丽”地暴露出来。姑且不论需求和开发的问题，我认为测试可以往前多走几步。
　　第一，  一定要进行测试设计，站在用户的角度，进行测试设计。时间紧张时设计的粒度可以只到测试场景，预期结果中包括检查的点。有充分的时间还是建议编写规范的测试用例，描述清楚前提条件、操作步、预期结果、优先级等。
　　测试场景必须覆盖所有改动的功能点，而且一定要进行全流程测试。保证该功能的修改不会影响整条流程。
　　第二，  一定要进行回归测试，这里的回归测试视情况而定，时间足够全量测试，时间不够，一定要对系统核心功能进行回归测试。例如金融行业的交易，回归测试场景必须包括的各类正常场景和重要的异常场景，保证版本上线以后，用户还能继续使用这些核心功能。回归测试需要对系统深入理解，判断用户核心业务场景。
　　第三，  版本如何极大低影响性能，需加入负载压力测试、稳定性测试、大数据量测试。
　　第四，  沟通，沟通，再沟通。把测试的场景全部列出来，给需求和开发过目，请他们协助判断一下是否有漏测，或者理解有误的地方。对于这种没有文档的项目，系统设计全部留在大家的脑海中，每个人理解可能都不完全一样，通过测试用例去统一大家的思路，保证我们测试的有效性。
　　第五，  如果明知道该版本对功能影响范围较大，而市场或者项目经理又催得很紧，一定要告诉他们风险非常大，具体表现在哪些方面。这样他们经过仔细斟酌，如果得不偿失是绝对会支持你的，如果他们能够承担风险，就会考虑上线。
　　经过以上这几个步骤，在这种无文档的“敏捷”项目中，测试作为最后一道关卡，一定能够发挥你的价值，成为项目组必不可少的一环。那时的你是不会出现在我开始提到的被问责的场景中的。