如
果system tester们仅仅是把自己看作领所当然存在的一个角色,那的确死定了。等什么时候 tester 这个角色的人员水平能达到与 dev
想类似的时候,估计这些问题就都容易理解。反观这10年来行业的发展,基本上还是在普及概念,形成行业的阶段,绝大多数人还没有想明白 test !=
tester != system test。
完
全无视行业发展,被淘汰只是早晚的问题。回头看看10年前的测试领域,能说清楚各种系统测试设计方法、系统测试流程、缺陷管理流程的人已经很牛了,真正精
通自动化测试/性能测试的人恐怕都是6、7年前才多起来的,而这3、4年腾讯、淘宝、百度的测试技术/能力迅速的超过了行业平均水平几个数量级。
想想这几年来面试的大量system tester,在谈到系统测试用例设计方法的时候,能举出的例子还是停留在输入框的长度限制之类,就一再的无语。再想想那些声称精通自动化测试,但是仅仅是看过QTP培训录像的,一提到测试工具开发就变成无法逾越的门槛,就继续无语。
测试人员是否对质量负责,这个本身就是基于一个错误的前提来讨论问题。咱们来试着提出一些问题“格物致知”一下。
1.测试人员是否对质量负责,这个问题是从何而来的?最早是谁提出来的?关于如何保障质量这个问题,在此之前是怎么个做法,如何演变成了这个问题?
有没有人讨论过类似:开发人员要对质量负责?QA人员要对质量负责?
以前农村自家给自己盖房子的时候,有没有预先明确一下,最后如果有质量问题,谁该负责?
只有2-3个人的做ios应用的创业公司,有没有划分一个对质量负责的人或角色?
XXX应该对质量负责,已经是典型的“划清职责”的做法,把一个在“过程”中酝酿出来,并且不断动态变化的事情,交给某个角色去处理。如果基于这个问题本身再讨论,也只是在围绕错误的前提寻找容易接受的说法而已。
其实我们原本应该是讨论“保障软件质量的最优/最高效做法”,而不是为了撇清责任吧。
2.到底应该由谁对质量负责?
项目经理?如果质量问题出在对需求的理解上,出在架构设计的问题,是否也要项目经理负责?项目经理有如此的全知全能还有用不完的时间和精力?
了解team中每个人的能力和经验,在需求、设计、编码、测试的各个环节,用最合适的方法让最合适的人都发挥出最大的贡献,持续的优化质量和预防各种问题--如果非要说项目经理对质量负责,个人理解这种做法还能靠谱
---------------------------------------
附:测试对质量负主要责任?
你的公司,产品发布时,是否要求测试说出个“产品质量是XX的”论断,如果发到用户那里出了问题,就首先打测试的板子,老大都在问“测试为什么没有测试出来”,仿佛测试是最后一道关、是质量警察?测试应该对质量负主要的责任吗?
我的观点:测试不对质量负主要责任,测试只起到质量辅助的作用;测试是一种服务,为其他角色提供服务,提供关于质量的信息。
为了说清这个观点,有必要先讨论一下:什么是质量、什么叫做对质量负责、对谁负责、谁定义的质量。
当然质量的定义有很多种,我比较赞赏Jerry Weinberg的定义”Quality is value to someone who
matters“,测试最主要的目的就是要找到那些削弱产品价值(value)的点,将这些与产品质量相关的重要的信息提供给项目决策者,以便他们做出更
准确的决策。
正如Michael Bolton所言,”Consider quality not as something simple,
objective, and abstract, but as something messy, subjective and very
human.“ 质量不是什么简单的事务,而是一个关乎产品、人、系统之间的复杂关系。
为了提升质量或保证质量,需要有方方面面的考虑,是那些产品的管理者们真正有权利决定使用什么开发方法和流程、雇佣什么样的人员、采用什么样的质量目标、如何度量、花多大成本等等来确保产品的质量,而不是测试人员。
作为测试人员,不要努力去影响别人做什么、怎么做,而是要聚焦于提供实时的、准确的有关产品的信息(问题和风险),以有助于别人做出更恰当的提升质量的决策。
测试是一种服务,为项目其他角色提供服务。当然,每一个角色都是为其他角色提供服务的。开发人员为测试人员提供”软件可测试“的服务,使得软件更容易测试;测试人员帮助开发人员测试他们的代码,使用专业的测试技能和测试思维。
测试人员、包括QA,都不应该将某种方法强加于开发人员,那是质量警察干的事。一是因为测试人员和QA都没有优势告诉开发如何开发质量更好的产品;二是因为当你强加某种东西给别人的时候,你获得的往往是假的数据。
征得Michael Bolton的同意,转译了他的一篇博文:http://www.taixiaomei.com/?p=50
其实,“负责”是个很重的词。对质量负主要责任的人,得有一定的权力做各种质量有关的决定。测试是否有权力或能力做这些决定呢?
质量本身是一系列活动的结果,当然最重要的是设计和编码,如果设计和编码都完全符合需求和用户期望,那也就不需要测试了。然而,我们的认知和智力都
是有限的,不可能那么完美,而且有时候用户都不知道自己的需求,还需要我们去引导(乔布斯理论),所以还是需要一个中立的或者第三方的组织来判断产品的实
现是否符合用户和我们最初的需求和期望,这就需要测试来给相关的利益关系者提供客观、准确的质量信息和评估了。
测试活动本身不能带来产品质量的变化。测试就是一个信息提供方,精确反映出产品需求的实现和在哪种情况可能给客户带来的风险就是测试的职责,当做一个质量播报员,就像最近的牛奶风波一样,我们只要把牛奶中成分的真实情况反映出来,剩下的就由用户或制造者来做决定吧。
质量是设计出来的,但设计者是人,也有考虑不足的,需要通过测试发现,发现后设计者进行改进,测试的职责是发现问题。设计和实现是有差距的,没有缺
陷的设计只是一个终极目标,只是一种理想,因此测试必须进行一种权衡,判断哪些缺陷是必须改进的,哪些是现在可以忽略的,这种决定不是仅由测试说了算的。我不知道哪个团队的测试人员可以做这个决策?除非你比开发人员还懂业务、你比项目经理还了解风险、你比客户还了解需求?
产品“零缺陷”只能是一个理想,即使排除时间和投入成本也是不可能达到的。但我们要把产品可能存在的潜在风险和失效条件找出来,发布与否这样的决定就不是测试说了算了,要看客户能否容忍这样的风险和失效,由决策者做成最终决定。
当然,测试这把尺子,只能提供有关产品质量的“相对”的信息,不是“绝对”的信息。实际上,“XX产品的质量就是什么样子的“这个论断没有人能给得
出。如果你能准确无误地说出”XX产品的质量现在就是这样“,
很快就会发现一个反例的出现将打破你原来对它的认识–当然,你根本无法准确无误地说出质量的样子,那是一个无穷的集合,就像测试是一个永远测不完的活一
样。因此,测试提供的信息只是相对准确的,不是绝对准确的,这个局限性也正是测试所面临的挑战。
不过,测试努力做到的是,用我们的专业技能和测试思维,尽可能学习了解真实的产品、发现别的角色意想不到的问题和风险,并报告给他们:“在XXX的
背景/上下文/场景下,XXX产品在XXX质量属性方面表现正常;在当前进行了XXX的测试后,目前XXX产品存在XXX的问题,如果XXX使用该产品,
会存在XXX的风险。”
说“测试对质量负主要责任”这样的说法是错误的,不是代表测试就和质量没有关系,实际上测试非常关心质量,并且测试的工作对质量有很大的影响。但同
时我们认为其他角色关心质量的程度一点也不
比我们小,或者不应该比我们小,大家共同对质量负责。但是像敏捷里的“完整团队”的说法,每个人都对质量负责、大家是个自组织团队的做法在现实中还是遇到
很多问题的,还是得有人做决策,做那些为了提升质量而采取什么动作的决策,这个决策者,首先得有权利做决策,才能控制了项
目,才能控制了质量,才能对质量负责。
也许在很多公司,是项目管理者有这样的权力吧。测试像一把尺子衡量产品质量后会给出测试知道的有关质量的信息,同时我们也很清楚,管理者那里还有很
多测试不知道的、同样也很重要的、有关质量的信息,管理者会基于所有信息作出最终的质量决策,可能是发布产品、可能是更改流程、可能是更改需求、可能是引
入工具。。。 管理者有做这些决策的权利和能力,他们会想办法让所有角色关心质量,所以,不是测试对质量负主要责任,而是决策者要对他做的决定负责。