monicazhang 发表于 2017-7-20 14:00:03

你知道“敏捷测试”吗?

又一次,关于“敏捷测试”到底是什么的讨论热闹起来,小编自己经历过很长时间的实践,后来也开始辅导团队、企业实践敏捷测试,现在就跟大家分享一下这些经验。 敏捷软件测试领域的权威作品,无疑是名称最符合的《敏捷软件测试:测试人员与敏捷团队的实践指南》,原作名《Agile Testing: A Practical Guide for Testers and Agile Teams》,作者是Lisa Crispin和Janet Gregory,推荐大家阅读。 如下是小编的一些看法: 敏捷软件测试就是在敏捷方式下开展测试工作的方式,是一种方式,而不是测试的类型、范围或阶段。 所以敏捷测试的专家,一定是整个测试方式的专家,意味着要涵盖测试类型、测试范围、测试阶段这几个维度,那通常就是整体或全局的顾问了,可以看作是传统所说的“测试流程顾问”,但因为敏捷里面,测试跟开发和其他环节密不可分,所以这个“流程顾问”只懂测试是远远不够的。 通常业内把敏捷测试当作是一种类型,例如,把敏捷测试看作是功能测试之后、性能测试之前执行的一种类型的测试,这就是误解。 手工、自动的区分,测试出身的都不一定搞得清楚,更不要说非测试出身的了。涉及到探索式测试,就更容易混淆,手工、自动,通常是指执行的手段,探索,指的是测试的目的。这意味着手工的测试不一定就是探索式的,而探索式的测试也不一定就是手工的。 虽然敏捷到底意味着什么,业内也有争议,但较为广泛接受的是从需求到产品的全过程,更全的是从概念到现金(from concept to cash)的全过程。 让开发人员专注于开发,让测试工具(谷歌的工程生产力)人员专注于提供支持测试(和其他生产力活动)的工具,让测试人员专注于研究如何用工具快速高效地完成业务的验证,才是一个合理的模式 当然,取决于这三类人群的心智模式的距离,距离越近的,这三类人群的分隔越不清晰,也更容易一个人搞定所有。心智模式越远的,越需要清晰的界限,也即三类人员, 然后强调紧密合作。我这个理念,我觉得在《设计心理学》里是有共鸣的,我们能够做好工作,取决于我们每天所接触的东西,与我们要完成任务所需的概念模式,是容易建立关联、检测进度和获取反馈的。这就是我说的心智模式。 如果最终产品和代码或程序的理念很像,那么程序员搞定一切,一点问题没有,例如程序员开发给程序员用的工具,因为他们本身就是用户,所以程序员搞定从开发到测试的所有任务,一点问题都没有。 如果最终产品运行的概念模式和构成单元(代码)的心智模式差距很远,那么程序员就不可能搞定一切。例如,银行的对公业务,作为程序员,最熟悉的是代码和代码运行的概念模式,而对公业务的基础构造单元和概念模式,则与之有很大的差距,想要依靠程序员完成对最终产品的完美验证,几乎不可能,或者说,会带来分裂和效率问题,因为要想形成对代码或业务的高度理解,是试图同时追求知识的广度和深度,要么就是不可能做到,要么就是浪费,带来极大的心智切换成本。 尤其是当涉及人员很多的时候,必须考虑分工。开发专注编写代码,但从需求到设计(需要实现哪些代码)的过程的合理性就很重要;测试专注理解业务从而合理地验证产品功能,但从头介入防患于未然就很重要;而提高效率则需要靠提供工具,工具需要开发,属于代码的概念模式,而工具的使用者又是我们希望更侧重业务的测试人员,属于业务的概念模式,好在这两块都不需要非常深的理解,所以我们需要专门的工具开发人员。这种分隔,就在不同类型的专业(=专职,请注意理解)人士和知识的深度、广度之间找到了平衡,当然,最重要的是一定要紧密协作,才能够解决问题。 另一方面就是原来那么多级的测试,如何处理,敏捷的思路是要针对更小的需求颗粒度,在迭代内完成所有相关类型、范围的测试(阶段跟时间有关,敏捷方式跟传统不同,打破了时间安排,所以阶段是完全不同的)。 我们解决问题的突破口在于,是否一定要“一个人”完成所有这些测试,还是“多个人”协作完成所有这些测试?以及,是否是同一个人完成这些测试的“生产”(=设计编写)和“消费”(=执行检验),还是可以分工以及借助其他技术手段完成。找到这些问题的答案,就是实践敏捷测试的关键。 如下是这种人力分布方式的一个例子: 而这些答案的知识,是存储在人脑之外的外部世界的,也即是组织的相关环境。我们需要通过外部世界的知识,来唤起我们脑中的信息,消化之后,得出我们可以运用于这个组织的具体的敏捷测试模式或流程。(这段话也是借鉴了《设计心理学》里面的描述)。(徐毅原创)
页: [1]
查看完整版本: 你知道“敏捷测试”吗?