测试用例评审的旁观记录
发布于 2024-10-01
1162
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
测试用例评审会摘要
日期与参与者: 2022年5月24日下午,测试用例评审会召开,会议参与者包括项目经理、研发经理、技术架构师、效能经理、前端技术负责人、业务架构师、测试人员、开发人员以及外部咨询顾问,共11人。
会议时长与问题: 评审会持续了70分钟,期间发现了11个需要修改的问题。
评审现象: 观察到的主要现象包括:
- 测试用例按照状态-事件-系统响应的三段论方式描述。
- 讨论需求含义占用了超过一半的会议时间。
- 测试中常常遗漏异常场景。
- 参会人员积极发言,勇于表达重要观点。
- 区分了成熟功能无需重复测试的需求与本期不实现的需求。
- 测试用例使用了思维导图进行描述。
- 部分问题在会议中即时得到了修正。
顾问建议: 顾问对测试用例评审提出了几点建议:
- 评审应以需求为主线,先解释需求再审查测试用例,确保所有需求都被测试用例覆盖。
- 建议使用不同颜色标注正向和反向测试用例,快速识别可能遗漏的异常场景。
- 分析各角色发现问题的数量,评估是否需要这么多角色参与,以提高评审效率。
- 将发现的问题分类分析,并制作评审检查清单以供参考。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 882K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
风险来源与风险分类的区别与联系
CMMI 1.2的RSKM 过程域的SP1.1为:Determine risk sources and categories,在该实践中明确区分了风险来源与风险分类。确定风险的来源和分类是为了全面、系统地识别潜在风险,合并类似风险的规避措施。风险来源用于在项目或组织内确定风险产生的原因。对项目来讲有许多风险来源,包括内部和外部的。风险来源标识了风险可能发生的常见领域。常见的内部和外部风险来源有:•
不练基本功,遇事多返工
俗话说,练拳不练功,十年一场空!基本功与天赋决定了一个人做事成功的概率,决定了一个人成功的层次。
缺陷清除率的简单分析
某项目采集了在一个迭代周期内缺陷的注入与发现数据。把缺陷注入分为了3个活动,把缺陷发现分为了4个活动,一个月内的统计数据见下表:某项目的缺陷清除率分析缺陷注入\缺陷发现Sprint planning设计与编码代码评审测试小计需求分析453 12设计与编码 27128测试 22小计4530342缺陷清除率33.3%62.5%96.8%100.0% 在此统计表中并没有采集到产品发布后的度量数据
阶段、交付、增量、迭代与里程碑的概念辨析
首先看阶段,无论敏捷还是瀑布模型,均会使用“阶段”这一表述,但通常更常用于瀑布模型。迭代则更侧重过程,一个迭代通常对应一个增量,也可能多个迭代共同构成一个增量,反之,一个增量也可以包含一个或多个迭代。在软件研发过程中,敏捷、瀑布等不同模型常会用到阶段、交付、增量、迭代、里程碑等概念,这些术语看似相近,实则各有定义、适用场景不同,理清其区别与关联,能有效提升研发过程的沟通效率与管控精度。其次是交付,这是一个通用性极强的概念,灵活应用于各种研发模型,无论敏捷还是瀑布,只要向客户交付产品,均可称为交付。
软件项目管理的成功原则
来源:希赛网 作者: 任甲林 1 平衡原则 在我们讨论软件项目为什么会失败时可以列出了很多的原因,答案有很多,如管理问题、技术问题、人员问题等等,但是有一个根本的思想问题是最容易忽视的,也是软件系统的用户、软件开发商、销售代理商最不想正视的,那就是:需求、资源、工期、质量四个要素之间的平衡关系问题。 需求定义了"做什么",定义了系统的范围与规模,资源决定了项目的投入(人、财、物),工期定义
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线