测试管理 现在大家都在用啥测试流程呀?

张狂天 · 2022年01月11日 · 最后由 兔子李 回复于 2022年01月13日 · 1154 次阅读

是传统瀑布(就是需求评审 - 开发(同时写用例)- 接口测试 - 测试),还是敏捷啊?
我们公司就是传统,现在想要搞敏捷,我们就是小部门,敏不敏捷我感觉没多大差别,问下大家都在用啥流程?

共收到 15 条回复 时间 点赞

敏捷测试流程,2 周一迭代,比传统的好太多了。关键是要自动化测试和功能测试配合并进才效果更好。

看项目和资源。给资源,让我做啥就做啥。
说实话,部分项目两者表现并没啥区别。有时候先天条件不行,搞敏捷就是个负担。

三周一个迭代,敏捷,就是有时候需求不明确,开会的时间都没有

😦 小公司哪有那么多人力去搞自动化 维护测试用例,点点点得了

看业务情况,一般 1-2 周一个迭代,最长的不超过 2 周。迭代过程基本也和楼主说的瀑布差不多,不过这个我理解是个软件开发流程都得这么走吧,顺序大部分情况下无法调整,因为相互依赖。

另外,不知道楼主这里提的敏捷,和这里提的传统瀑布有啥差别?
敏捷的具体落地不同公司有很多不同差异的,有的地方小型瀑布(就是需求拆到 1 周内能搞完的粒度)也会认为是敏捷。

陈恒捷 回复

产品(项目领导)说让我们先看看敏捷年后考虑搞。我感觉就是产品省得写文档了,因为 “工作软件胜过全面的文档”,产品一句话开发直接开搞。并且 “响应变化胜过遵循计划”,那就开发改完直接上线。
这两种我感觉做起来都是貌似快了,但项目必定会引入混乱,还不如正常瀑布流。

A11 回复

是啊,就那几个人,还想搞各种流程,不是折腾吗

Max 回复

大佬的敏捷流程跟传统瀑布有啥区别呀

Ouroboros 回复

是这样,我们现在简单瀑布都搞不明白就搞敏捷,我感觉还不够出问题的

风不止 回复

敏捷不是靠开会了解需求吗,不开会怎么定需求啊

张狂天 回复

如果你们的敏捷=不写文档和开发完直接上线,这是敏捷的典型反面教材。这玩意不叫敏捷,叫乱来。。。

工作软件胜过全面的文档 != 只要软件不要文档
响应变化胜过遵循计划 != 只要响应不要计划

人家说这句话的场景是当时大部分用的都是最传统的瀑布流,文档要写得差不多有代码那么详细(你找个政府类项目的完整文档看看就知道了,需求说明、概要设计、详细设计,每份文档都是几十页甚至过百页的文档,像写论文一样),计划一排就是排好几周而且中间不能随便变,所以才说这两句呼吁大家不要舍本逐末。你上面说的这个明显就是矫枉过正了。

也可以看看这篇文章,里面提及了几个常见的敏捷理解误区:https://www.scrumcn.com/agile/scrum/4074.html

陈恒捷 回复

文章看了,受益良多,多谢恒捷大佬~

一周两迭代,saas 看客户时间上线,挺难受的

是传统瀑布(就是需求评审 - 开发(同时写用例)- 接口测试 - 测试),还是敏捷啊?

无论瀑布还是敏捷,都是这个流程,因为确实有先后顺序(难道还能不出需求就开发吗?难道还能没开发出东西就测试吗🐢 ),个人理解核心区别在于每个阶段的时长,以及每个阶段具体包含的要素。

【以下个人理解,可能不对】
瀑布模型相对久远了,现在估计很传统的软件开发(传统 toB)或许还在用,它强调的是单产品单时间只有一个版本或很少的版本分支,后面的阶段要等前面的阶段完全结束,每个阶段要有十分完备的书面文档。在当年硬件资源匮乏,发布难度高,客户关系比较稳固,客户对交付日期要求比较松的大背景下,会有一定的科学价值。

敏捷上,网络资料更多,应该没有 toC 的公司不走敏捷模式,只是标准和不标准的区别。与瀑布最大的区别就是发布时间更短,每次发布带更少的特性,强调快速发布试错、拿到时长反馈、迅速迭代特性,这个方法论与现在公司竞争用户市场的局面下显得很适用,具体理念 11 楼 贴的链接已经说明得很清晰了。

另外,流程建设是要分阶段的,人少产品小的情况下就应该轻量高效,因为人少就不会存在严重沟通 gap,有啥事你在工位吼一声大家都知道,这个场合下强调敏捷,要不就是领导者希望团队提前建设相关氛围方便后面扩张人员,要不就是领导者单纯想实践一下这种模式。case by case,适合才是最好的。

我理解我们的目前属于半敏捷,在研测流程上配合还做不到敏捷,有周更版本和月版本形式

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册