专栏首页授客的专栏测试思想-测试流程 敏捷测试与开发之我见

测试思想-测试流程 敏捷测试与开发之我见

下文本着实用性原则,谈谈敏捷测试与开发相关的一些想法,如有不同意见或想法,欢迎提出~~

1、 团队优先

个人觉得,不管做啥,应该把“团队合作”放在第一位。如果团队本身没有凝聚力,没有向心力,那团队就是一盘散沙,有力无处使。“敏捷”也不例外,敏捷宣言中第一句就是“个体和交互 胜过 过程和工具”,充分强调了团队合作的重要性。

如果把“敏捷团队”比作一个木桶,那么团队中的每个角色就是组成木桶的木板,团队的效率就是桶里的水。根据木桶原理,团队中只要有任何一个角色不够效率,不够敏捷,那么整体的效率也就受到影响。

所以,我的观点是,“敏捷”的前提是“团队优先”,重视团队,重视团队中的每个角色,无差别的对待每个合作成员,让每个角色、成员有动力,有激情的弥补自己的短板,让自己更敏捷,从而促进整个团队的敏捷。

所以,应该跳出旧的思维,看看到底是自身不敏捷,还是其他成员、团队、组织的不敏捷影响了整体的“敏捷”。

问题:

产品经理、策划人员、设计人员(UE、UI),开发人员,测试人员、运营人员……都做到敏捷了么?

2、 需求为主

所有的一切源于需求。由需求而生,随需求而灭。

所以,我的观点是,“敏捷”从“需求”开始。

自然而然,从产品经理、策划人员的“短板”抓起。从需求说起,书上说,他们需要做的第一件事情就是整理需求 --- 编写用户故事

3、 编写故事

书上说用户故事代表对用户、客户有价值的功能,即用户(客户)需求,不含过多的需求细节。

不过个人觉得产品经理、策划等“产品人士”,其专业性一般强于非专业人事,通常有他们自己的想法,所以可以预先以非故事的方式,比如注释、要点的方式进行简单记录。

关于用户故事的编写要求,可网上搜索相关资料,这里暂时不提供。当然,也不必要完全参照网上说的一定要是某种格式,关键是怎么方便,有效。怎么样写一份好的需求,是合格的产品人士必备的技能

4、 讨论细节

书上说,需求的细节要在“对话”中获得,并在确认部分得以记录。

这里,团队成员在聚在一起,头脑风暴,针对3中的每个用户故事,逐个展开关于需求细节,并记录讨论结果

特别说明:

很多事情,唯有参与,才有认同.....。

5、 版本规划

确定当前迭代的版本包含的需求及优先级安排

6、 任务量评估

开发人员评估大致大致的工作量。

7、 原型设计

将讨论结果以以实际的原型、界面展现出来,是构建一个真正产品很好的方法,同时把重心从“需求文档评审”转移到“原型(Demo)评审” ,以原型评审为中心,辅以必要的文档说明,作为原型的补充,也是去掉无用的功能定义文档、需求文档可行方法。

原型设计好了,共享给相关人员查阅,以便及时获得反馈,及时更正,如果时间来得及,最好是评审下原型

8、 项目开发与用例设计

开发人员根据原型进行项目、产品开发,测试人员根据用户故事、原型(假定原型已经被认可的情况下)来测试设计用例。

说明:

这里为了方便,建议用类似xmind工具或excel等来写编写需要评审的测试用例,方便评审,同时,建议编写一份按功能模块汇总的用例。

这里有些人可能会觉得写两份用例,麻烦,耗费时间,但我认为实际花不了多少时间,因为执行中可在“复制黏贴”的基础上完成,而且用例某种程度上也代表了产品整体,有一份按模块展开的用例,让你很容易看到“大局”,不仅在测试时起到很好的提醒作用,而且还方便优化用例。 再进一步,要是把汇总的用例,写在管理系统,比如禅道上,是不是容易分配任务、跟踪任务、统计任务执行等情况呢?

备注:用例是需要维护的,需要不断优化的,试问,做测试的亲们,你们能一次性就写出很完美的用例么,特别是在很时间短,项目赶的情况?不能吧,,,所以如果每次都在前一次基础上修改,迭代,效果是否会好点呢?

例子

汇总的用例:

提交评审用例:

说明:从图上也可看到,这种情况下的用例,会是比较零散的,针对故事点,具体执行时,很多时候需要重复编写用例,即重复的时间投入。。。。

备注:

很早前我写过一篇关于精简测试用例的文章,后面看了下,发现好像执行性不高,删了,没分享出来。最近今天思考了下,发现用例还是可以精简的,精简用例的出发点是“用例主要是起提醒作用”,这个观点也是隔壁公司某项目负责人交流时,她提到的。当时没怎么在意,现在想来,发现还是挺有价值的一句话。结合上面的格式说明,用例名称,模块、故事名,验证点,一般是不能少的,那可不写的是啥?答案是:步骤、预期结果。当且仅当你一看用例名称,即测试验证点,就能想到步骤和结果时(比如翻页,密码大小写验证等),那么可省略,因为这时候,用例名已经起到了足够的“提醒”,……

9、 开发自测

开发发布前,根据测试提供的用例进行简单自测,当然,开发自测环节的可能性是基于规范成熟度、工作任务量等因素的,一开始就让他们自测,估计会要了他们的命。

备注:开发如果有看下测试给的用例,哪怕是瞄下,说不定就看到没注意的细节了,,进而可将bug于测试前修复,要是再细看下就更好了……知道大致做到什么程度,才不会让测试抓住辫子,才算完成了开发工作,,,这里体现的就是敏捷的思想。

10、内网测试

QA进行内网测试,这些测试可能包括单元测试,接口测试等等,至于能做到哪种程度,就看各方面的配合了

11、外网发布与走查

12、下一轮迭代

重复流程3~11

难点说明:

结合实际,流程3~6 要怎么做?

方案要求:

1)可执行性高

2)效率高

3) 可维护性高

工欲善其事,必先利其器,根据方案要求,选择一款合适的工具、合作平台,就变得很重要了。

参考方案

方案1)

流程3、用Mindjet Mindmanager、XMind记录用户故事,举例如下

流程4、相关人员聚在一起讨论需求细节并记录结果

参考做法:

1)准备好一台电脑,一台投影仪,大家坐成一圈,看着投影仪逐条讨论故事细节

2)专人记录,讨论期间专人记录讨论的结果

说明:这里这里形式不固定,用笔记本,投影仪啥的,主要是考虑怎么样方便大家参与进来讨论,方便快速记录

流程5、将相同版本的需求打包在一起,安排优先级

到这里,差不多形成了一份简单的需求文档了,,好了,共享吧,电子文档就是方便,大家不用可以去记忆讨论结果,不用拿相机拍照,每人一份不是神话^^

6.开发人员进行评估工作量

这里是在讨论会上解决,也可以会后解决,看项目复杂度,难度等因素

备注:用excel会不会好点?待定

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 测试思想-测试执行 测试过程中的用例维护

    3、 已经失效的用例:用例对应的需求已经变更,而测试执行使用的用例还是按原需求编写的用例。

    授客
  • 测试思想-测试设计 精简测试用例编写

    大家都知道,测试用例的一个核心作用就覆盖测试需求,尽可能的减少漏测,同时提高测试效率。再细想想,这种核心作用的本质也就是一种“提醒”作用。

    授客
  • 测试思想-流程规范 用例优先级定义与使用规范 V1.0

    对软件测试过程中的用例级别进行详细描述及标准化定义,明确不同测试阶段的测试范围,减少测试冗余投入,提高测试效率,建立测试质量基线,减少生产故障事件。

    授客
  • Influx Sql系列教程二:retention policy 保存策略

    retention policy这个东西相比较于传统的关系型数据库(比如mysql)而言,是一个比较新的东西,在将表之前,有必要来看一下保存策略有什么用,以及可...

    小灰灰
  • Struts2 DefaultAction (默认Action)

    <default-action-ref name="index"></default-action-ref> 默认的action的引用;当别人访问这个actio...

    Hongten
  • PMI-ACP 敏捷项目管理——模拟试题4

    1、在第五次sprint审查期间,团队获得产品负责人对所有功能的签署同意。但是,产品负责人注意到在第二次sprint期间开发和验收两个功能不能正常工作。随着新功...

    隔壁老李头
  • PMI-ACP 敏捷项目管理——模拟试题3

    1、一名经验丰富的团队成员没有参与每日站会,导致他们落后于审查活动。敏捷管理专业人士应该怎么做 A 要求管理层解决 B 提醒团队成员基本规则 C 通知产品...

    隔壁老李头
  • [转] PHP读取HTTP接口如何处理超时

    原文地址:https://www.jianshu.com/p/446ea7aaea86

    陶士涵
  • SSM框架的Morning公益商城系统

    猫宁晨报公益商城是中国公益性在线电子商城,以商城B2C模式运营的公益在线商城,是一家致力于将传统公益商城互联网化的创新公益商城。

    Rookie
  • 「镁客晚报」戴尔宣布中国4.0规划,将解决100万人就业

    镁客网

扫码关注云+社区

领取腾讯云代金券

玩转腾讯云 有奖征文活动