测试的角色 (Test) 要独立出来么 ?

独立出来的测试角色怎么才能发挥作用?

有些成功人士和成功的公司号称没必要有独立的测试角色 (Test), 你怎么看?

来自: 现代软件工程讲义 9 测试 QA 的角色和分工 - SoftwareTeacher - 博客园

有关作者

@程序员邹欣

• 现任微软亚洲研究院技术创新中心项目主管,主要负责研究成果向产品的转化.
• 从1996至2003年起在微软Outlook产品团队从事开发工
• 2003年至2005年,在微软Visual Studio Team System产品团队负责软件质量管理工具的开发.
• 他利用业余时间写了
  • «移山之道– VSTS软件开发指南»(2007年),
  • «编程之美–微软技术面试心得»(合作,2008年).
• 他还在清华大学软件科学试验班讲授 «现代软件工程»课程.
• 邹欣于1991 年获北大计算机软件专业学士学位;
• 于1996 年获美国Wayne State University(韦恩州立大学)计算机软件专业硕士学位.

有关报道:

• 如何成为”好导师”,”好学生”–“馒头”铿锵三人行

文章梗概

最近又看到一些关于开发人员要不要负责测试的讨论. 例如: http://www.aqee.net/on-testers-and-testing/

大多数的开发团队并不需要一个独立的测试角色. 即使有一个,他的所有的开发时间比上所有的测试时间应该 >20:1. 

[注: 这个翻译就有错误, 原文指 开发: 测试 的比例应该 > 20:1 ]

我正好在写相关的教案, 也来凑个热闹.

…

明确两个概念: 软件测试 (Test), 软件质量保证工作 (Quality Assurance)

…

分工理论: 分工的起源是由人的才能具有自然差异

…

分工促进劳动生产力的原因有三:

• 第一,劳动者的技巧因专业而日进;
• 第二,由一种工作转到另一种工作,通常需损失不少时间,有了分工,就可以免除这种损失;
• 第三,许多简化劳动和缩减劳动的机械发明,只有在分工的基础上方才可能.

…

没有分工的时候, 原因 有好几个:

…

问题:既然有专人负责, 那我就不用负责了!

…

问题: 盲目信任 “专业人士”扮演的角色

… 软件的质量往往受最差的角色的影响最大

…

问题: 为了自己角色而做绩效优化

…

问题: 无明确责任的分工

…

那么独立的测试角色怎么才能发挥最大作用? 从上面的坏现象中, 我们不难总结出来. 其实 MSF 原则都讲到了.

• 充分授权和信任(Empower team members)
• 各司其职,对项目共同负责(Establish clear accountability and shared responsibility)

…

引起网上讨论的两篇文章在这里: http://sriramk.com/blog/2012/01/testing.html

中文翻译在: http://www.aqee.net/on-testers-and-testing/

…

结束:

一位网友说得好: 分工是社会和行业进化的结果. 开发和测试其实是软件工程的两分支. 不同的软件／服务需要不同方式和程度的测试. 独立专业的测试等同于第三方代表客户对产品认证.

拉拉扯扯这么多话, 团队/个人/角色到底应该怎么办呢? 我认为,

• 在初始阶段 (新项目, 团队进入一个新领域, 人员刚进入一个项目), 每个团队成员都要尽量打通各个环节, 多负责, 把所有事情都搞懂, 培养通才.
• 当项目/产业发展到一定阶段 (进入阵地战的时候), 要大力提倡分工合作, 培养专才.
• 把自己项目的架构和流程做好, 让所有人都能比较容易地进行 Quality Assurance 的工作.
• 培养”大家都要做QA, 专人负责量化的Test, 有条件多做测试自动化”的文化.
• 要明白自己项目的特点, 人员的特点, 产业的特点. 避免照搬别人的做法. 不要听说某某伟大的系统的开发/测试比例是多少, 就哭着喊着也要同样的比例…

思考题:

…

你在某团队做测试,兢兢业业已经三年, 今天大家传说公司认为开发人员应该做测试, 所以不需要专职的测试人员了.

你怎么想? 你能否做到:

明确列出过去三年你对团队的贡献? 除了"认真执行测试用例"之外,  你对团队整体的"质量保证"还有什么独特的贡献?
有理有据地说明, 没有专职测试人员, 项目会有什么风险?
这三年的经历在你的简历怎么写出来? 你比三年前更容易找到工作么?

这三点搞不清楚的, 还是改行吧.

是也乎

关注邹欣和他的 «现代软件工程»课程 很久了, 因为和 GoalPythoniCamp - 蟒营 忒象了!

不过,今天推荐此文章,主要倒还不是因为 QA/测试 的探讨, 而是:

怎么写出完备的文章

从文章的标题可以看出:

• 现代软件工程讲义 9 测试 QA 的角色和分工
• 这是一个大系列的讲义
• 而讲义是有标准的内容结构要求的:
  • 一定的内容,可撑足规定时长的课时
  • 足够的背景知识点,可以引导学生建立足够稳定的理解支撑
  • 足够的问题展开,以便学生有一个宏观上正确的把握
  • 余味足够的作业命题,必须综合应用课程内容,以及额外的探索/思考/实践 才能完成
• 其实,讲义的规格要求,也正是一篇 完备 的议论文的结构要求
  • 在网络中发布文章,无法预判读者的格局
  • 所以,一般要先设定范畴,以免被断章取义,成为他人的武器
  • 对问题的行业背景,可对比的其它行业发展,进行综合叙述,建立起讨论的语境
  • 然后再进行推论
  • 配合实际常见的问题,以及对应分析,应用已有的态度/体系/知识进行解答
  • 最后,再强调/明确一下文章对问题的态度/方案/建议/倡议…
• 即,一篇 完备 的文章应该是:
  • 有节制的 ~ 约定在指定范畴中探讨
  • 开放的 ~ 自个儿不是天子,无法金口玉言,只是进行严谨的探讨
  • 认真的 ~ 是为了解决问题的,分享自个儿经验的
  • 有态度的 ~ 不是为了站队或是讨好谁,是基于自身真实体验的

这样的文章,才值得学习/收藏/传播,以及实践, 当然,也只有这样的文章,才可能引发实践,并获得反馈,进一步完备下去.

巡阅

• 150113 Zoom.Quiet checked