质量切入点都在哪儿呢?
关于敏捷项目里质量保障的文章,大家应该看了不少了。
质量已经不再是简单地通过“发现 Bug -> 修复 -> 验证”这个流程来解决的问题,而是通过一系列的质量活动来保证的目标,正所谓预防为主!
我们的目标也不应该再是找多少数量级的 Bug 了,而应该是在通往高质量的这条路上,我们能够设置哪些关卡来预防质量出现问题(设置关卡的过程其实就是建立质量流程的过程),与此同时,尽量保证各关卡的工作是有价值的,避免各关卡的工作重复度太高。
不要单纯地认为质量就是指交付产品的质量,它同时还包含整个项目过程中的质量流程是否最优,质量工作是否高效。我个人给到的公式是:项目质量 = 流程 + 效率 + 产出物。
那么,这个过程中的质量切入点都在哪儿呢?下边是我梳理的部分内容。
Test strategy
-- 测试策略不是制定出一个就一用到底的,而是需要阶段性地进行调整。
这里的重点是,Test strategy 一定是团队达成一致的产物,而不是某个人制定出来的。
Backlog Grooming / Backlog Refinement
-- 对 Backlog 里的卡片进行一次洗牌。
IPM / Sprint Planning / Iteration Kick off
-- 明确下一个迭代的重点是什么。
Card Grooming
-- Dev 捡卡到开卡前对卡片进行分析、任务拆分、细节补充。
Card Kick Off
-- 开卡,Dev 邀请 BA、QA 一起 Go through 卡片细节,确保大家的理解是一致的。
In Dev
-- Dev 对卡片进行开发。
项目条件允许的情况下,这个环节最好 Pair 进行,可以互相讨论、互相补充、互相“监督”、互相 Backup。
PR Review
-- 另外 1、2 名 Dev 对提交的代码进行 Review。
Desk Check
-- Dev 与 BA、QA、UX 的 mini showcase(有些项目中,客户方的 PM 或者 PO 也会参与到 DC 当中,判断是否符合心理预期,尽早给出 Feedback,尽早做出调整)。
In QA
-- 对卡片内容进行 Double check,但更多的时间应该花在 Regression test 和 Exploratory test 上。
其实我更倾向于称 In QA 阶段的工作叫 Double check,而不是 Testing。
我们已经可以通过 Unit test、Integration test、API test、Dev 自测以及 DC 过程中的 mini showcase 来保证每张卡片的质量,这些都属于 Testing。而我们在 In QA 阶段需要做的更多的是去挖掘在之前阶段没有 cover 到的部分(Regression test + Exploring test)。
Done
-- 对卡片做闭环。
别看只是简单的一个做闭环的动作,依旧存在质量风险,尤其对于新人来说。
经常有同学跟我说很纠结卡片能不能或者应不应该拖到 Done:
卡片在测试环境上测好了,但是线上环境还没搭好,所以没办法在线上环境验证,能拖到 Done 吗?
卡片的测试工作已经完成,但是流水线坏了,能拖到 Done 吗?
有一张之前的卡,已经在 Done 里了,接手的时候,发现里边列的很多场景都没有被执行过,能把这卡再拖回来吗?
单纯地让我回答“能”或者“不能”,sorry,回答不了,我只会反问你,团队定义的 Done 的标准是什么?如果你也不知道,记到小本本上吧,然后回去 Drive 团队把这件事情落实一下。
Daily stand up
-- 团队每天对自己的工作内容、进度进行简短更新。
不要小看这 15 分钟时间,可能其中的某一分钟就能解决你的 Blocker 或者效率问题。
Retro
-- 对迭代(Sprint / Iteration)中发现的问题进行回顾,总结并找到解决方案,让团队更好地发展。
Could happen at any time
-- 任何时候都可以发生的事情。
其实全篇提到的“质量切入点”,是在整个项目过程中,为了达到最终“高质量、高效率”的效果,可以做的任何事情(包含但不限于上述所列举出来的流程和内容)。这些事情可以是提问,可以是实操,可以是沟通,可以是总结。
所以,质量切入点在整个项目当中无处不在,想要找到它们,质量流程建立起来了吗?
版权声明: 本文为 InfoQ 作者【QE_LAB】的原创文章。
原文链接:【http://xie.infoq.cn/article/86b230f77195273889df21faf】。文章转载请联系作者。
评论