惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

F
Fortinet All Blogs
S
Secure Thoughts
月光博客
月光博客
美团技术团队
雷峰网
雷峰网
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
N
News and Events Feed by Topic
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Forbes - Security
Forbes - Security
W
WeLiveSecurity
P
Proofpoint News Feed
阮一峰的网络日志
阮一峰的网络日志
爱范儿
爱范儿
G
GRAHAM CLULEY
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
AI
AI
Last Week in AI
Last Week in AI
Google Online Security Blog
Google Online Security Blog
Schneier on Security
Schneier on Security
云风的 BLOG
云风的 BLOG
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Recent Announcements
Recent Announcements
Webroot Blog
Webroot Blog
T
Tor Project blog
Cisco Talos Blog
Cisco Talos Blog
N
News and Events Feed by Topic
罗磊的独立博客
The Register - Security
The Register - Security
Blog — PlanetScale
Blog — PlanetScale
T
Threat Research - Cisco Blogs
博客园 - 【当耐特】
Apple Machine Learning Research
Apple Machine Learning Research
人人都是产品经理
人人都是产品经理
T
The Exploit Database - CXSecurity.com
www.infosecurity-magazine.com
www.infosecurity-magazine.com
B
Blog
腾讯CDC
Microsoft Azure Blog
Microsoft Azure Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
H
Hacker News: Front Page
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Engineering at Meta
Engineering at Meta
Latest news
Latest news
IT之家
IT之家
D
DataBreaches.Net
博客园 - 司徒正美
N
Netflix TechBlog - Medium
V
V2EX
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知

博客园 - Jackei

《清单革命》 《我所知道的软件测试自动化》- 关键字驱动的过去和未来 奔向 33 岁了 《我所知道的软件测试自动化》- 关键字驱动的过去和未来 《我所知道的软件测试自动化》- 引子 看看五年前的自己,有些惭愧 2012 11 11 程序员的思维修炼 - 从新手到专家(2) 程序员之外的人是否应该活下去? 阅读分析源码的规则 程序员的思维修炼 - 从新手到专家(1) 《激荡三十年(上)》的笔记 - 3 如何测试一个编译器? 2010-7-1 麻木的IT公民:293个公司人压力和心理调查 醉里挑灯看剑 我的C语言也很牛B啊! 王小波,《孔子》,傻大姐 对于每个复杂的问题都会有一个简单但不准确的答案
2012-4-26 对测试的各种吐槽
Jackei · 2012-04-28 · via 博客园 - Jackei

今天不淡定,集中吐槽了。修炼了这么久,还是没啥长进。唉。

集中汇集一下,自己反省。

我们需要什么样的测试?其实@段念-段文韬 这篇文章http://t.cn/zOpW23h已经讲得很清楚了。tester们从业时间短的,可能还不太会思考:做一个项目的目的和目标是什么,test这个事情到底能贡献什么?当前普遍的dev与system tester 的分工模式是如何形成的?更高效可靠的做法是什么?我们如何实现去实现?

如果system tester们仅仅是把自己看作领所当然存在的一个角色,那的确死定了。等什么时候 tester 这个角色的人员水平能达到与 dev 想类似的时候,估计这些问题就都容易理解。反观这10年来行业的发展,基本上还是在普及概念,形成行业的阶段,绝大多数人还没有想明白 test != tester != system test。

完全无视行业发展,被淘汰只是早晚的问题。回头看看10年前的测试领域,能说清楚各种系统测试设计方法、系统测试流程、缺陷管理流程的人已经很牛了,真正精通自动化测试/性能测试的人恐怕都是6、7年前才多起来的,而这3、4年腾讯、淘宝、百度的测试技术/能力迅速的超过了行业平均水平几个数量级。

想想这几年来面试的大量system tester,在谈到系统测试用例设计方法的时候,能举出的例子还是停留在输入框的长度限制之类,就一再的无语。再想想那些声称精通自动化测试,但是仅仅是看过QTP培训录像的,一提到测试工具开发就变成无法逾越的门槛,就继续无语。

继续。上个IT人才的分布图。今天system tester同学们认真思考一下,如果你对于工程和质量的理解深度不如QA,项目管理的理解不如PM,对操作系统、数据库、开发语言、中间件、计算机网络的理解不如dev,但声称“我更懂被测系统业务,我的测试思路不同”。那你就该明白为什么工作5年后跟dev有那么大差距了。

 

回复《测试对质量负主要责任?》————事实再次证明,回复比原创容易的多。。。。。

------------- 开始 -------------- 

测试人员是否对质量负责,这个本身就是基于一个错误的前提来讨论问题。咱们来试着提出一些问题“格物致知”一下。

1.测试人员是否对质量负责,这个问题是从何而来的?最早是谁提出来的?关于如何保障质量这个问题,在此之前是怎么个做法,如何演变成了这个问题?
有没有人讨论过类似:开发人员要对质量负责?QA人员要对质量负责?
以前农村自家给自己盖房子的时候,有没有预先明确一下,最后如果有质量问题,谁该负责?
只有2-3个人的做ios应用的创业公司,有没有划分一个对质量负责的人或角色?
XXX应该对质量负责,已经是典型的“划清职责”的做法,把一个在“过程”中酝酿出来,并且不断动态变化的事情,交给某个角色去处理。如果基于这个问题本身再讨论,也只是在围绕错误的前提寻找容易接受的说法而已。
其实我们原本应该是讨论“保障软件质量的最优/最高效做法”,而不是为了撇清责任吧。

2.到底应该由谁对质量负责?
项目经理?如果质量问题出在对需求的理解上,出在架构设计的问题,是否也要项目经理负责?项目经理有如此的全知全能还有用不完的时间和精力?

了解team中每个人的能力和经验,在需求、设计、编码、测试的各个环节,用最合适的方法让最合适的人都发挥出最大的贡献,持续的优化质量和预防各种问题——如果非要说项目经理对质量负责,个人理解这种做法还能靠谱。 

------------- 结束 --------------