软件测试周刊（第19期）：以能力流程指标和工具为轴心打造一流的质量保证部门

Posted 2021-06-30 毕小烦

这里记录过去一周我们看到的软件测试及周边的行业动态，周五发布。

本周刊开源（GitHub: SoftwareTestingWeekly ），欢迎提交 issue，投稿或推荐软件测试相关的内容。

科普

奶头乐

奶头乐（英语：tittytainment），又译为奶头娱乐或奶嘴娱乐，，是一个合成词，来自于英文“titty”（奶头）与“entertainment”（娱乐）两词的组合。

据德国作家 Hans-Peter Martin 称是由美国前国家安全顾问布热津斯基创造的，特别泛指那一类能让人着迷、又低成本、能够使人满足的低俗娱乐内容。

奶头乐理论是想解决什么问题？

当然是阶层之间的利益冲突。

怎么解决呢？

由于 80% 的财富掌握在另外 20% 的人手中。为了安慰社会中“被遗弃”的人，避免阶层冲突，方法之一就是让企业大批量制造“奶头”——让令人沉迷的消遣娱乐和充满感官刺激的产品（比如：网络、电视和游戏）填满人们的生活、转移其注意力和不满情绪，令其沉浸在“快乐”中不知不觉丧失对现实问题的思考能力。

文章

1. 我对CTO的理解

欧拉

01 错误都是自上而下

大凡一个好的 IT 公司，必有一个牛逼的、有个人魅力的 CTO，大凡一个烂公司，必有一个昏庸无能、圆滑世故、东郭先生的CTO。

混乱永远都是自上而下，而不是从下面传染给上面，可惜很多的管理者都持有与此相反的混帐逻辑。

所以正确的思维顺序应当是：成事在人，先有人，后有 process，后有流程、考核、制度，出现错误，肯定是人犯了错，再美好的3P (Plan、Process、Project)，如果没有合适的人才支撑、实施、贯彻执行，都是没有用的花架子。

02 CTO 要有技术魅力

CTO 最重要的是热爱技术、理解技术、选拔技术人才，知人善任。至于后面的所谓的执行力、战略眼光、制定计划、精通各种Process、leadership，那是后话，只有前因才能促使后果。

03 招募 CTO，不要只贪图名气

不要招募自称擅长流程改进的纯管理人才，没有技术经验的支撑，根本就是赵括谈兵，浮沙盖楼，这是铁血经验，不服气的尽可以去招募这些人对公司进行自杀式攻击。

如果你需要 CTO，尽量从公司内部寻找，寻找那些正直热血、愿意公司向好、有良知的、有思想视野开阔的、追逐技术的的人。如果确实没有，再向外撒网。

04 好的 CTO 有识别人才的能力

技术人才的选拔是从 CTO 开始，而 CTO 最重要的职责，就是网罗合理的技术人才。

2. Shell脚本的质量保障体系

何文鑫

Shell 脚本在与操作系统的交互上具有编写快捷、使用方便的好处，但是，对很多人来说，Shell 脚本很难驾驭。

如何搭建出一套质量保障体系，来提升 Shell 脚本的质量呢？

01 Shell 脚本的静态检查

ShellCheck 是Shell脚本的静态检查工具，类似于 Java 的 FindBugs。

你可以将一段 Shell 脚本粘贴到ShellCheck主页的演示框中，很快，演示框会提示你脚本中有哪些潜在的问题。

如下图所示：

主页地址：https://www.shellcheck.net/

当然，你还可以在本地使用 ShellCheck，通过命令或与编辑器集成，具体请看：https://github.com/koalaman/shellcheck

02 Shell 脚本的单元测试

相比于静态检查，单元测试可以理解为动态检查（即运行时检查）。静态检查检查语法错误，而运行时检查检查业务逻辑。

Shell 脚本的单元测试可使用：

• Bats-core ：https://github.com/bats-core/bats-core
• shUnit2：https://github.com/kward/shunit2

03 Shell 脚本的编码能力

• Google Shell 风格指南：http://zh-google-styleguide.readthedocs.org/en/latest/google-shell-styleguide/contents/
• 社区 Bash 风格指南：https://github.com/azet/community_bash_style_guide
• 格式化工具：https://github.com/mvdan/sh

04 Shell 脚本的持续集成

将质量保障手段无缝嵌入到整个开发流程中。

05 人的意识和能力

工具是最简单的，而人，才是质量保障最关键的因素，所以要不断的提升人的意识和能力才能拥有更好的质量。

3. 如何进行高质量的缺陷分析？

嵩华

软件开发中的缺陷隐含着极高的价值，但是许多组织都仅仅忍受了缺陷带来的成本和后果，却让价值白白溜掉了。

那么，如何做好缺陷分析，让价值最大化呢？

把握这 5 个要点。

01 及时总结，设置卡点

缺陷分析的最好时间是缺陷修复完成的时间。此时记忆最新鲜、也能早收益。

可在流程中设置卡点：

当缺陷被设定为已修复状态、或者设定为已关闭状态时，强制把缺陷分析设定为一个流程卡点，不写分析不让改状态。

02 结对分析，小组总结

把结对分析作为制度：结对既形成了知识方面的互补，一定程度上消除了思维盲点，也通过结对形成了更深入的讨论，也提前进行结果的“验收”，提高分析的质量。

团队定期讨论学习：团队定期对重要的缺陷分析结果进行讨论，既是对小组成果的验收，更有利于在团队成员间形成传播，互相学习。

03 负面清单支持下的全量分析

缺陷分析的目的是提升，重在解决那些“未知的未知”的问题。使用负面清单过滤问题，凡是负面清单不存在的，都进行缺陷分析。

每个团队都应该维护自己的负面清单，例如：

• 偶发问题
• 已经列在改进项中的问题（不断扩充）

04 可操作的结果

缺陷分析应该产生有价值的洞见，足够的深度是重点。可用 5 Whys、鱼骨图等分析工具。

检验分析深度是否足够，最直接的指标就是产生的结果是否是“可行动的”。如果一个结果是不可行动的，往往意味着深度或者抽象不够。

05 团体学习，机制建设

学习型组织并不总是容易建立。除了上述心智模型和操作方法之外，组织机制往往是成功的重点。

主要有以下几点：

• 是长期存在的团队
• 建立持续学习的心智模型
• 持续维护和利用本组织的智力资产

关于智力资产：

分析结果最后可能会是流程改进、编程习惯和编程规范、代码评审的检查单、设计能力的提升、引入某些新的工程实践如实例化需求等。

工具

1. Git/GitHub 中文术语表

Linux 中国 

Git 和 GitHub 已经成为了开发者的基础工具，尤其是参与开源软件开发时经常会使用它们。

本文收集整理了 Git 和 GitHub 中常用术语的中文译名及其解释。

2. 一人公司方法论

Easy

一人公司就是建立在个人品牌之上的公司。

它是说整个公司的业务和品牌影响力都主要源于基于一个人。它周围可能有一些辅助运营的团队，有一些外包、有一些兼职，甚至全职助理的角色，那也是一人公司。

如果你想知道如何运营一人公司，本文适合你仔细阅读。

https://github.com/easychen/one-person-businesses-methodology

3. 谷歌新开源的脚本工具 - zx

小秋

Bash 很好，但是在编写脚本的时候，人们通常会选择一种更方便的编程语言，javascript 就是一个很完美的选择。但是标准的 Node.js 库在使用之前需要许多额外的操作，比如安装、引入库等。

zx 提供一个包装器 child_process，用于转义参数并提供合并的默认值，让开发者可以更方便的编写脚本。

项目地址：https://github.com/google/zx

示例如下：

#!/usr/bin/env zx

await $`cat package.json | grep name`

let branch = await $`git branch --show-current`
await $`dep deploy --branch=${branch}`

await Promise.all([
  $`sleep 1; echo 1`,
  $`sleep 2; echo 2`,
  $`sleep 3; echo 3`,
])

let name = 'foo bar'
await $`mkdir /tmp/${name}`

方法

1. 如何打造一支牛逼的项目团队？

Tanα

假如你是项目经理，怎么才能打造一支牛逼的项目团队呢？

试试 PBAA。

01 Professional（专业度）

你要有足够的专业度，站得高才能看得远，要有战略视角，精通业务全流程和场景痛点，再结合专业的管理方法正向干预团队。

02 Business Value（商业价值）

你要让团队清楚的认识产品/项目的商业价值。 先解构再建构。

• 首先要解构。立项的时候，就要让大家明白搞定这个项目会产生多大的收益，对市场和社会将带来怎样的影响。
• 然后再建构。帮大家建立联结，为了实现这个巨大的商业价值，集团的战略目标、组织的目标、项目的目标分别是什么，一定要映射到每个人身上，每个人承担的个人目标是什么。

这个过程中，每一个人都能认识到个人的价值和成就感，以及在整个价值链条上的贡献。

03 Atmosphere（团队氛围）

要打造一个相互尊重和开放的工作氛围。

这就得立规矩，有硬性制度要求，更得有柔性的行为规范，避免不必要的争吵和冲突。

所谓硬性制度要求，就是角色职责、流程机制、业务基准这些，大家能够达成共识，再形成书面文件。而柔性的行为规范，就是从你开始，以身示范，以身作则。

04 Alignment（一致性）

你要使出浑身解数，保障过程与计划的 Alignment（一致性），让每个人各阶段对项目的承诺都能实现，包括时间、成本、质量等各要素，从立项到收尾，始终如一。   

2. 如何让技术大佬失去理智？

陈雪涛

产品经理如何让技术大佬失去理智？

01 给一个让人似懂非懂的 PRD，细节还不清晰，当他细问时质疑他的理解能力。

• PRD = 天书：产品大佬写 PRD 最好拿出小学写作文的水平，前后可以不一致。
• 细节不清晰：产品经理这么忙，所以有时候考虑不周全也很正常嘛，对细节不清晰，所以才体现了技术大佬的重要性。
• 这个需求很简单：不就是实现一个简单的配置界面么，为什么讲了几遍你听不懂？

02 时不时来个临时需求，还说是领导要做的。

• 下班前提紧急需求：临下班前，用 1 分钟讲完一个紧急需求，然后在花 4 分钟讲了领导是如何催的急，最后问一句：今天晚上能上线嘛？
• 临时改需求：当技术大佬已经进入了 code 环节，产品大佬可以偷偷的修改 PRD，刚一点也可以把技术大佬喊到跟前，口头修改需求，这样的修改重复三四次效果更佳。
• 领导说要做：当项目价值的不清晰的时候，产品大佬可以把锅甩给领导，向下传递“敷衍”。 “这是领导要求做的，而且就要这么做”。 

03 在技术设计时指手画脚，质疑他的工作量，过程中经常打断其工作，有需求问题时玩消失。

• 又出现一个 bug：出现问题就直接在线上问题反馈群@技术大佬
• 保姆式参与设计：有技术追求的产品大佬就应该大闹技术评审会，字段命名不规范，设计不合理一个都不能放过。
• 项目过程消失：在开发过程中，产品经理最好玩消失。技术大佬有什么问题，让他们自己读文档解决，解决不了让他们自己猜。
• 给工作量打折：每当技术大佬评估完一个项目的工作量之后，产品大佬就把工作量打个 5 折。

04 项目排期时紧时松，上线时间和运营时间倒挂，让他开始怀疑人生。

• 偶尔的项目排期相当紧凑，偶尔的项目排期又十分松散，让技术大佬开始怀疑自己的骨干位置。
• 技术大佬加班提前3天上线，项目上线后 30 天还没开始运营。

05 项目总是没有后续，产品没有长期规划，让他学会抄袭，遇到他实现不了的需求就打开竞品，从源头上毁灭他们的信仰。

且行且珍惜。

3. 如何打造一流的质量部门？

Ganesh Panchapagesan

一家企业想要快速发布高质量的产品，又想尽可能的压缩成本，那就需要一个一流的质量保证（QA）职能部门。

如何打造世界一流的质量保证职能部门呢?

企业需要将其现有的 QA 以能力、流程、工具和指标为轴心进行转化。

进行四种基本转变：

• 零瑕疵转变：零瑕疵发布是软件开发的新标准。用户对质量越来越挑剔，修复成本随之变高，这就要求企业将产品开发一步到位。产品需求要精确，质量要端到端全程监控。
• 敏捷转变：采用敏捷和类似的开发方法，每月或每周发布产品，交付时即达到可以预测的质量。
• 技术转变：通过新技术交付优质产品，要求企业开发新的 QA 能力。
• 价值转变：世界一流的质量部门，将更快发布新产品、以质量为先导的竞争差异化、客户认同和降低商业运营成本，作为其新目标。

驾驭四个重要杠杆:

• 员工：

• • 将员工的职责从测试转型为端到端质量管理

• • • 好处是在产品的整个生命周期对质量流程进行辅助、指导和治理。
    • 且有助于降低整体的质量成本（CoQ）和出现瑕疵的密度。

• • 能力描述、员工发展和组织文化的管理，都是人员转型的关键。
  • 将实用的培训和积极强化的原则，融入组织的文化 DNA，并且定期激活这些 DNA，以确保员工在适应新技术和新方法的同时，不断保持高水平的绩效。

• 流程

• • 能将不同的 SDLC 阶段中的流程顺畅地进行整合。
  • 通过用户宣传、统一测试战略和测试设计自动化、对现有的流程进行“原样”评估式的盘点等强化流程。

• 质量衡量与分析法

• • 制定标准的规模度量方法，例如功能点和复杂度点数。
  • 优秀的组织会采用以结果为基础的质量模型，以转化 IT 团队在估算方面的行为。

• 工具与基础设施

• • 工具和基础设施的转型是 QA 转型的第四大杠杆。
  • 工具转型的第一步是整个企业内部的工具整合和标准化。
  • 整合的核心可以是以活动为基础的工具标准化，或者是以堆栈为基础的整合。
  • 下一步就是将各自为政的各部门中使用的工具整合，从而统一掌握多个 SDLC 活动中的质量情况。

评估标准：

1. 产品瑕疵泄露率；
2. SDLC 瑕疵密度；
3. QPI（Quality Performance Indicators，质量绩效指标）；
4. 软件生命周期各阶段的 CoQ（Cost of Poor Quality，质量成本）；
5. 按功能点计算的成本。

言论

1、这... 就是测试

2、

很多人觉得他们在思考，但实际上只是重新安排自己的偏见。

—— 威廉‧詹姆斯

3、

图片

1、当测试人员在 2 小时内发现了 5 个BUG，并且高兴的告诉了开发人员。

2、真实...

订阅

本周刊每周五发布，会同步更新在微信公众号。

微信搜索“毕小烦”或者扫描下面的二维码，即可订阅。

如果文章对你有帮助，请随手点个赞吧！

(完)