敏捷软件测试的七个关键成功要素(3)

　　如果团队成员喜欢一次开发一大块功能，鼓励他们采用步骤式的方法。提出问题：“这个故事的核心业务价值是什么?这块代码的最基本路径是什么?下一步干什么?”建议大家编写任务卡片以编码和测试小增量，记录设计概念和确认测试和测试自动化策略。

　　编码和测试是同一个过程的组成部分

　　对敏捷思想不熟悉的人经常会问敏捷测试人员：“在所有故事完成并且可以测试的时候你会怎么做?”经验丰富的敏捷实践者会说：“测试人员必须贯穿整个迭代，整个开发过策划那个。否则就会失败”。

　　测试人员基于客户提供的例子编写测试，以帮助开发人员理解故事并开始编程。测试和例子提供了一种通用语言使所有人都参与到软件理解中。测试人员和开发人员在编码时紧密合作，他们也会与客户紧密合作。开发人员向测试人员展示他们编写的功能，测试人员向开发人员展示他们发现的异常行为。测试人员随着编码进展编写更多测试，开发人员是其通过测试，测试人员进行更多探索性测试以了解是否生产了正确的价值。每一个敏捷迭代包含了若干持续、快速、增量的测试——代码 —— 测试——代码——测试迭代。

　　当这种合作和反馈周期被打断，并且测试与开发分离时，糟糕的事情会发生。如果故事是在编码之后的迭代中被发现的，开发人员不得不停止新的故事，回忆代码是如何实现上个迭代的故事的，修补它，并且等待其他人测试。在软件开发中没有什么几个事实，但是我们确定缺陷发现的越早，修补的成本越低。

　　当编码一直由测试指导，编码的同时进行测试，我们更有可能达到客户预期的行为，提供客户所需的价值。测试是团队的职责。如果团队没有这种观念，让所有人想一想对质量的关注、对发布优秀产品的期待和采取哪些措施来确保团队实现目标。

　　实践之间的协作

　　单个敏捷开发实践如持续集成能够发挥作用，但是多个敏捷实践的组合比各个部分相加要大。测试驱动设计、共有代码所有权和持续集成一起促进快速反馈、持续改进代码设计和快速产生业务价值。自动化测试很好，但是使用自动化测试驱动开发，随后是探索性测试以发现缺陷或者弱点，分多层次更好。

　　某些实践单独操作并不好。没有自动化测试，重构是不可能的。通过迷你瀑布型的方式发布小版本会丢失敏捷开发的所有优势。如果你的现场客户没有做决定的授权，那么他对团队的价值有限。

　　敏捷实践是互补的。花时间理解各个实践的目的，想想如何利用全部优势，针对什么对团队有用做出深思熟虑的决定。

　　与客户合作

　　测试人员对敏捷团队的最大贡献之一是帮助客户理清需求并设定优先级，通过预期行为和用户场景的具体例子描绘需求，并把这些例子转换为可执行的测试。测试人员使用业务的领域语言和开发团队的技术语言。我们担任优秀的辅助者和翻译。

　　千万不要阻碍开发人员和客户之间的直接沟通。鼓励尽可能多地直接交流。使用“三方协作”方法。当需求丢失或者被误解，客户、开发人员和测试人员需要一起解决问题。请客户经常在白板或者其他虚拟工具前讨论问题。如果客户发布于不用的地区、国家，那就使用任何能找到的工具来加强沟通和协作。电视会议、即时消息和 wiki不能完美的替代面对面的交流，但是也比发邮件或者什么都不做要好。

　　保持大局观

　　我们发现测试人员有大局观，通常从客户的角度看问题。开发人员通常关注于实现当前的故事，虽然他们使用测试来指导，但是不得不关注于需求的技术实现。

　　大局观对团队贡献巨大。测试驱动开发，如果完成得很好，单独的代码没有缺陷。如果新的功能导致一些应用明显不相关的部分崩溃怎么办?一些人不得不考虑这种对较大系统的影响并引起团队注意。如果我们忽略了一些可能惹恼客户的细节怎么办?新的UI可能没什么缺陷，但是如果背景颜色使文本难以阅读怎么办?这都是最终用户会注意到的问题。

　　使用敏捷测试象限作为纲领来帮助规划测试覆盖所有范围。使用测试金字塔思想确保测试自动化的良好投资回报率。通过测试指导开发有助于确保你没有丢失重要的事情，但并不完美。使用探索性测试了解系统应该如何工作，测试应该指向哪个方向。让你的测试环境尽可能与生产环境类似，使用反映现实世界的数据。勤于重新构建一个生产环境类似的场景，如负载测试所需。

原文转自：http://www.ltesting.net