测试路漫漫, 吾将上下求索. 两年多开发经验, 六年整测试经验. 比较熟悉web自动化测试, especially in Ruby & Watir. 正在探讨Agile 测试, Junit testing in Agile. 联系方式:myfengliu@hotmail.com

QA 要不要做"周扒皮"

上一篇 / 下一篇  2008-12-14 09:47:39 / 个人分类:Communication

前天晚上, 跟一PD闲聊, PD提到我们有些QA在测试中跟"周扒皮"似的? "周扒皮", 大家都知道,在旧社会就是一反面角色,压榨长工的一家伙.但是把周扒皮用在测试中,说实在的,这还是我第一次听说.要是硬把周扒皮定义在PD对QA的评价, 我认为可能是有两方面因素:
  1. 原则性强,用PD的话说,把PRD当圣旨51Testing软件测试网0^+uk+W5K+`e(v3k
  2. 对PRD扣的很细,挖地三尺
对于第二点,在此先一放. 对于第一点,从中不难看出,PD和QA在沟通上出现了问题,尤其是在PRD的理解上.遇到这种问题一般怎么办呢,如果是PRD确实写的模糊,我想最简单的就是跟PM进一步确认即可;如果是PRD写的比较明确,但是PD做出来的东西跟PRD确实有出入,在这种情况下,有两种选择,一可以跟PM确认(其实是跟PM谈判,我们没有做成那样,你看这样行不行),二是,QA坚持原则,给PD发Bug(自然会被PD认为,把PRD当圣旨).
51Testing软件测试网!^/Z4BaV6^
其实是不是把PRD当成圣旨,就是QA要不要当这个"周扒皮",我想视情况而定:
51Testing软件测试网C BgC9Sh(Mc}
如果QA在对某一行业知识,经验相对比较浅,而且对PD引入的出入确实不认同,我想最好还是按照PRD办事,坚持原则发bug,以免被引入歧途.即使认同PD的做法,也需要跟和PM进一步确认.这个"周扒皮"一定要做.
2n+l$B`'M4UwR0

C-V6{+k.S@'L0
如果QA比较资深,对行业知识也是比较资深,甚至在某些方面胜过PM,针对这中问题, QA可以主动出击,跟PM讲清缘由,"PD的这种做法可能回更好", 这样既赢得了PD的好感,又对产品有利,何乐而不为呢. 显然,这时候"周扒皮"就做不得了.

%Il%[1Rx1d,n}0
总得来说,对QA来说,对于吃不准得东西,宁做"周扒皮",也不要随PD"浊流".

TAG: Communication

 

评分:0

我来说两句

Open Toolbar