全员 QA 的四种实践

2020/04/09 TDD 技术管理 共 1618 字,约 5 分钟
拔菜集

上篇《代码写完了,QA 可以测了》用了“流氓”码农们的一些典型语录,来说明工匠对于测试的一些价值观:

  1. 把测试当作开发的一部分。

  2. 事情要么“做完”,要么“没做完”,没有“做完了,但是”。

  3. Test First,往往会告诉QA哪里可能有bug,而不总是被QA告知。

  4. 把测试当作一种设计过程。

然而,价值观或者文化不是关于如何说的,是关于如何做的。

作为一个管理者或者Scrum Master,有什么实践可以让团队从流氓开始走向工匠呢?

下面结合本人经历,按顺序推荐4个配套实践:Event Storming,开发拆解Story,Example Mapping, Test Case Map Review。

NO.1 DDD 之 Event Storming

时间:新的 Epic 或 Feature 启动时。

人物:Scrum Team, SME, End User。

有个常见的荒唐事实:开发团队作为解题者,往往不很清楚问题是什么。

他们只负责交付产品经理提的“需求”,而不理解需求背后真正的业务问题,而那,才是我们要解的题。

让团队理解真正的业务,不是一件容易的事情。事实上,各种陡峭的“群体学习”曲线,总是软件开发面临的最大的困难。

软件研发是个学习的旅程,软件只是副产品。—— 记不得名字的某外国人

Event Storming 最大的作用之一就是加速团队对业务的群体学习,建议在一个 Epic 或者 Feature 启动之前进行。

会议的产出对业务问题的一致性理解,和一个共创的 Domain Model。

NO.2 开发团队拆 Story

时间:Refinement meeting。

人物:Scrum Team。

很多团队是产品经理(PO)来拆 Story 的,这很不高效。

我们都知道计算机算法里的“分而治之”:解题的关键手法是分解问题。所以开发团队作为解题人,把大的 Story 分解成小的 Story,再自然不过了吧?

另外一个重要的目的是,培养团队“拆”的习惯,工匠级的程序员,无时无刻不在“拆”,拆需求,拆任务,拆类,拆函数,拆 test case。这可谓第一心法。

哪有什么天才,我只是把别人写代码的时间都用在拆解上了。—— 不愿透露姓名的工匠程序员周迅

NO.3 BDD 之 Example Mapping

时间:Refinement meeting。

人物:Scrum Team。

这个是拆 Story 的延续,每个 Story 都有一些“业务规则”,这些规则在 PO 传递给团队的过程中可能就遗漏或歪曲了,所以让开发团队针对每个核心的业务规则,举些例子出来。

这样可以进一步澄清模棱两可的需求,确保开发对需求的理解是准确的。

Example Mapping  

NO.4 Test Case Map Review

时间:Sprint 开始后,Story 开发完成前。

人物:QA 和 Dev 主导。

Backlog Refinement Meeting上的 Example 不全,但足以让团队开始开发。进入开发后,QA 的任务之一是继续精化那些 Example,确保它覆盖足够的场景。

注意这里不是设计完整的 Test Case,而是

用脑图的方式列出所有的场景。

跟开发去 Review,大家讨论并确定,这些场景哪些用单元测试覆盖,哪些用集成测试覆盖,哪些用手工测试。

Test Outline

上图是我司一个例子。这就是 Test First,本质就是以终为始。

NO.5 总结

工匠级的团队首先有好的工程实践,所谓工程,就是做事的方式方法。

我们把开发团队定位成解题人,而不是一个盲目的执行者,所以我们的工程方法是:

  1. 理解问题 (Event Storming)

  2. 分解问题 (开发拆解 Story)

  3. 不断确定对问题的理解和度量 (Example Mapping 和 Test Case Review)

软件只是这些工程实践的副产品。

这些实践是在预防 bug,节省的是后面找 bug 的时间。同时这些都是团队实践,不是个人实践。它们背后共同的原则是:反分工,反传递。

它们简单,但很不容易,一个团队花一年能熟练掌握这些实践,就很了不起了。原因下一篇说明。

你们的团队有哪些团队实践去保证质量?你们是基于什么原则去选择的这些实践呢?

文档信息

Search

    Table of Contents