“沟通”成了最重要的技能之一
敏捷宣言里讲：个体和交互胜过过程和工具，客户合作胜过合同谈判。在内部需求上，开发人员就是我们的客户。而我在加入团队后所做的第一件事，就是搬位子到开发人员旁。当然，是被要求这么做的。一开始还有点不适应，毕竟我们被分离开了曾引以为豪的独立的测试团队，这和传统的观念是相悖的。不过在经历过几个测试阶段后，这么做的好处就体现了出来。
以往我们总要等到一个正式的版本，才可以开始测试，否则过多的介入会打乱开发计划。而现在，程序员就坐在我对面的隔间，他一抬头就说：“嘿，X功能做好了，我跑了一遍没问题，你来试试看？”结果我过去试了试，bug出来了。程序员的反应则是：“好，我马上改”。——这样一个bug从发现到修正，最多不超过半个小时。而以往，我要等到版本正式提交，再build好，再up好，发现bug后还要通过提交bug管理系统，等待系统发邮件给程序员。如果恰好程序员忘记开邮箱了，那就可能要更多的时间。
事实上这里面还有更多的细节。我相信大多数测试人员会和我有同样的经历，在发现并提交一个bug时，我们写了大量的文字来描述bug的环境，bug的重现步骤；程序员修正bug时，也自信满满的说，该bug已修正。但当你一复查时，却发现你所认识的那个bug还在，而程序员完全理解错了你所说的bug。而现在，你所需要做的，只是抬一下头，把问题说出来，直接和程序员进行沟通，让他能够准确的理解你的意思，甚至包括你对于该bug的分析。接下来一切就十分好办了。
此外，有时有些bug确实不是那么容易重现的，你需要和程序员配合操作，才能发现其中的蛛丝马迹。我们现在最常做的一种合作就是，由我来制造环境，按重现步骤操作，由程序员在另一端跟踪调试代码，一边沟通，一边进行，这样就能很准确的发现问题，并且能很快的得到修正。
仅仅是几句话的沟通，就能将一个bug在最短的时间内修正，这节省了多少时间？这皆得益于比以往更便捷的沟通。而我们所做的，不过是移动了一下位子，减少了我们之间的沟通成本，却大大的提高了开发效率——我已经记不清有多少bug在还没提交之前就被消灭掉了。但这也对我们测试提出了更高的要求，虽然之前的我们也很强调沟通能力，但现在由于需要更频繁的沟通，我们对沟通能力的提高也变得也越来越重要，成为了最重要的技能之一。
说到这里，其实我们已经能感受到，测试的角色定位已经变了。因为敏捷开发中，要对质量负责的是整个团队，这一目标就要求测试人员不再是一个独立的质量监督部门，而是要融入到整个团队中，成为开发中不可分割的一部分。
调整测试用例的粒度
敏捷宣言里还说，可以工作的软件胜过面面俱到的文档，响应变化胜过遵循计划。那么我们是不是可以都不要文档，不用写用例了呢。我想，如果你的项目是一个“Hello world多国语言版”，大可以如此。但如果是面对一个大型的，多人的，在线的，角色扮演游戏，还是算了吧。
此文章共有3页 1 2 3 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
