yiding_he 2008-4-25 20:22
真想骂我们公司QA
公司原来也有一个质保部，但 QA 的角色并不明确。自从过了 CMMI3 之后，QA 就如同土地爷一样突然钻出来了，每天除了文档就是文档，到处惹是生非不说，你还得把他当佛爷一样供着。我们搞开发的是特不满意。我就纳闷了，QAQA，号称“质量保证”，却坐在那里跟个大爷似的，需求、设计、开发、上线、维护，这几样事情一点都不去参与一点都不去了解，怎么去保证质量？你也许会说，我们靠文档来保证质量。靠文档保证质量？那是放屁。我见过一些例子，设计文档写得很漂亮，但是实际写出来的代码是稀烂的。同一份设计文档，给 100 个程序员写，能写出 100 份不同的程序出来，质量差得天远。这根本反映不了任何东西。需求文档也是一样，看上去很工整很具体，但实际上可能用户要的就不是这个东西，你 QA 检查得出来？评审也是的。评审完了，当事人心中自然有数，你 QA 又不懂业务，写出来给你你也看不懂，你怎么保证质量？项目做得好你就有功，项目做得不好你也无过，还可以成天的发邮件告诉你你要写这个啊，你要写那个啊，你这个没签字，你那个没审核，无谓的增加 N 多工作量，这到底是保证质量还是在拖后腿？[size=1][color=silver]如果想要保证项目质量，就请不要做一个虚有其名的 Quality Assurance，而是做一个实实在在的 Quality Assistant。[/color][/size]
[[i] 本帖最后由 yiding_he 于 2008-4-25 20:56 编辑 [/i]]
泥泥虫 2008-4-25 20:39
不知道楼主又想说明什么，请问下QA他如何做回事一个实实在在的QA呢？很想知道，这种牢骚帖子貌似发了也是被喷的。
yiding_he 2008-4-25 20:55
算了，最后一句就当我没说，因为这样的 QA 不要也罢。
jimmyseraph 2008-4-25 21:52
也许是公司给QA的定位不合适，也许是这些QA能力不行，那么这样的QA不要也罢，这句话没错。不过楼主太激动了些。
[quote]靠文档保证质量？那是放屁。我见过一些例子，设计文档写得很漂亮，但是实际写出来的代码是稀烂的。同一份设计文档，给 100 个程序员写，能写出 100 份不同的程序出来，质量差得天远。这根本反映不了任何东西。需求文档也是一样，看上去很工整很具体，但实际上可能用户要的就不是这个东西，你 QA 检查得出来？评审也是的。评审完了，当事人心中自然有数，你QA 又不懂业务，写出来给你你也看不懂，你怎么保证质量？[/quote]
显然楼主对需求、设计文档了解不多，设计文档写得好，那么代码就不会写的差，设计文档描述了设计思路、上下文环境、模块划分、数据结构、接口关系、模块具体实现方式，一篇好的设计文档就应该是给100个程序员，只会写出同样的一份代码！不要以为这是不可能的，我参观过一家在印度的知名IT公司，他们就能做到！
需求文档更是重要，这是每个质量工程师都非常关注的东西，不要误解QA不懂业务，一个称职的QA首先是这一业务领域的专家，即使有些QA确实不懂这一块业务，他也可以通过让相关专家、客户参与需求评审的方式进行需求管理，需求管理这一块在CMMI中的描述是很明确的，每个称职的QA都应该知道怎么做。
看到你对评审的描述觉得太可爱了，“心里有数”这个说法实在太不专业，你怎么让大家知道你心里有数？评审发现的问题你怎么让其他人知道你确实做了修改？你怎么保证你的修改是符合问题提出者的真实想法？说白了很简单，是问题就要文字记录下来，要跟踪。QA不要看评审发现了什么问题，要看的是这些问题你是不是跟踪解决了，明白了吧。呵呵。
[[i] 本帖最后由 jimmyseraph 于 2008-4-25 21:53 编辑 [/i]]
hjjlearning 2008-4-26 11:06
jimmyseraph
写的很好哈，像我们没有QA的公司才是惨，没有详细的需求，设计，评审
导致开发出的产品很不稳定，出了问题也没有什么跟踪，不知道到底找谁，，，
我到是想有规范总比没有规范要好，只是很开发人员可能抵制文档，认为只要写好代码就是好的开发人员。
这还是一种观念的问题
puchonghui 2008-4-26 14:28
光有流程是没用的
一个好的流程需要有相应的技术能力才承载
举例来说
写设计文档的人他们是否真正具备写设计文档的能力？
如果实际能力达不到
纯粹为了满足某一个所谓的完善流程
那就毫无意义了
另外所谓的流程改进
首先要做的事情并不是看原有流程缺少些什么环节进行弥补
而是应该看原有的流程有什么多余的环节
把多余的环节立刻砍掉
因为这个是会直接影响进度的
qq102568183 2008-4-27 16:51
LZ那个公司的QA做的只是配置管理的活。。。:L 应该是CM
[[i] 本帖最后由 qq102568183 于 2008-4-27 16:54 编辑 [/i]]
luoyear 2008-4-28 08:08
流程 技术 人 三个因素一个都不能少。
对于小团队的开发，在某种程度上来说，更轻量级的流程，纳入更有效率的技术和牛人可能就能把事情更有效率的干好。
对于大团队，复杂系统的开发，团队管理的复杂性，知识管理的复杂性促使人们必须following一定的规则办事。同时，把必要的质量控制措施如测试，评审和文档化的工作做好，有利于提高沟通的有效性和在前端就把事情做好。
我想楼主更大的困惑在于其公司的QA试图把所有的项目置于同样的成熟度的基础上管理吧。与其事后起冲突，还不如在计划阶段就与QA合作，商量出适合本项目的轻量级但不是完全抹杀的过程来。
liucui513 2008-4-28 12:09
如果公司想要发展扩大规模，那就应该制定相应的规范，将文档之类的都制定好，并通过技术评审纳入公司配置库，这些对于今后其它的项目都是有用的，都是经验数据，慢慢地公司也就会有了自己的经验财富库及度量库。
当然，如果公司只想停留在小团队的发展，那就另当别论了。
cool2miao 2008-4-29 11:51
看了LZ写的那些话，我忍不住心里的怒火想痛骂你一顿，就通过你说的那些话，你根本就不懂QA到底是在做什么，请你先了解好QA到底是做什么的在讨论再发怒好不好，拜托！QA工作通常不会去深入了解项目过程中具体某个文档内容是什么，结构怎么样，更不要提代码了，QA所做的那些文档报告目的是什么你知道吗？那些文档的用处就是从流程上将项目导入正规化，完整化，凭什么？凭你们填的那些数据，分析你们那些数据，从中发现可能存在的隐患，QA工作靠的是大脑，利用的是手头上那些管理文档，如果你认为整天深入代码的QA就是一个可以保证质量的QA，那不是“QA”那是因该是“DEV“。需求上有没有达标，程序上有没有过关，拜托那是测试负责的那不是QA管理范围，QA是掌控项目过程的。一个公司管理流程上都不规范谈什么品质保证，遇到某些不配合的PL，特别是那些开发，公司才真算是完了，脑子整天想的是会写代码就是王者，拜托Copy&Paste的开发朋友们，多亏有了你们，不然测试还真上不了岗了。
我的话有些激，不过也正常，做QA前我做了三年的测试，那时期才真叫爽，一群开发都不知道在干嘛，看不起测试不会写代码，那么就让你们尽情的写，尽情的改，用BUG折腾死你们，我做到了。
chengxq 2008-4-29 12:10
[quote]原帖由 [i]cool2miao[/i] 于 2008-4-29 11:51 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=958871&ptid=113146][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
看了LZ写的那些话，我忍不住心里的怒火想痛骂你一顿，就通过你说的那些话，你根本就不懂QA到底是在做什么，请你先了解好QA到底是做什么的在讨论再发怒好不好，拜托！QA工作通常不会去深入了解项目过程中具体某个文档 ... [/quote]
能否赐教一下，你三年的测试以及QA的经验！
cool2miao 2008-4-29 12:52
[quote]原帖由 [i]chengxq[/i] 于 2008-4-29 12:10 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=958895&ptid=113146][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
能否赐教一下，你三年的测试以及QA的经验！ [/quote]
从心理
多从客户角度去想，要对你所做的负责，要对本职工作负责，要么不做要做就做第一，如果你做到了，那么就就让这种荣誉永远维持下去，直到你离开这个位置。虽然在这个过程中有些“残忍”，但是它是我的人生价值的体现
手段
对于这点只能凭经验来，找需求的漏洞，找出两件事情之间的矛盾所在，在测试员眼里程序永远都不会完美。
有一件事情我想问你，当你发现项目中某个功能问题特别多的时候，你会怎么去做？我告诉你当时我只有一个想法，那就是让这个功能重构，通常开发方面不会选择这么去做的，那么你的目标就是“逼”他们不得不去那么做，即使你没有权利更改需求，即使你没权利要求重构，但是BUG能让你实现这一目标。作为测试最好能给自己定一个永远完成不了的目标，对于这点你自己去理解很难解释。
至于QA，说实话我担任了1个月都不到，谈不上经验，但这个过程中体会不少，成长也不少，发现公司管理流程上的问题也不少，CMMI才刚开始学，不过我已经开始将公司引入这方面了，目标就一个要做就做最好的QA。
chengxq 2008-4-29 13:55
[quote]原帖由 [i]cool2miao[/i] 于 2008-4-29 12:52 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=958924&ptid=113146][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
从心理
多从客户角度去想，要对你所做的负责，要对本职工作负责，要么不做要做就做第一，如果你做到了，那么就就让这种荣誉永远维持下去，直到你离开这个位置。虽然在这个过程中有些“残忍”，但是它是我的人生价 ... [/quote]
谢谢！我也刚开始搞CMMI很多都不太清楚，到时候再咨询你啊
51testingmm 2008-4-30 11:34
如果QA真的不重要,你公司干嘛过cmm3
zhongmg108 2008-4-30 19:01
楼主的这个想法在开发人员与项目经理人员中具有一定的代表性；实际上，是公司的培训不到位，开发人员对项目开发流程不了解或不理解，也不知这些文档的作用，不知如何写好这些文档，实际是需要积累软件工程方面的知识。项目经理在这方面需要起到带头作用。当然QA的工作方式、沟通方式可能也有问题。
实际上质量体系不只是流程和QA，还需要其它的支持，如培训、评估、人力资源等等。
eve_lincoin 2008-5-1 11:52
有文档就不错拉,lz,别抱怨了,我们单位连需求都没有,pm就说了句,我需要应收应付,你去网上当个下来看看别人怎么搞的,然后就完拉,我测试根本就不知道应该怎么样才能实现它们所说的预期效果,在我这种情况,有个文档太重要了,就算是做样子的文档也比没有的好.
一个公司的规范,肯定先从文档做起,有文档比没文档的好.
red-hat 2008-5-3 11:54
冷静点！！好好考虑一下
hdc163 2008-5-3 16:17
不要发牢骚！没有QA你会按过程开发？
musk 2008-5-4 09:08
感觉这个是很有代表性的问题。下面人的回答非常精彩，特别是某个参观了印度知名IT公司的人的感受，不知道国内的中小型公司什么时候才能达到一份好的需求文档就能让不同的程序人员开发出基本相同程序的程度。
ccq613 2008-5-4 11:48
yiding_he
开发测试本一家，开骂，先骂自己。
爽了自己再爽别人
maggie_xiao 2008-5-4 14:25
LZ的心情可以理解，但是是否也应该换位思考一下问题呢？还有既然大家对QA的工作这么不满，有没有试着沟通呢？发牢骚是解决不了问题的。
lncyjunjie 2008-5-4 22:10
好的QA
好的QA应该参与过项目的各个阶段，至少是了解其中的业务。
hellen_ma 2008-5-5 10:03
:L
icetea_plh 2008-5-5 11:05
欠缺沟通哦
derekzhang 2008-5-5 12:52
像你这样，开发你也是不行，做什么事情不要总找别人的原因，反问你一句，你有做了些什么。自己考虑考虑吧，如果这个QA不行，老板早就让他走人了。看来他还是可以的。
阿妮妲 2008-5-5 14:21
站在对方的立场看问题,你就不会生气了.:)
jjjwxl 2008-5-5 14:31
回复 1# 的帖子
有时候不是QA的问题，也许问题出现在他的上级，不要拘泥于一点。做好自己的事情，适当给一些善意的建议，不要存在仇视在工作中。
cjchm 2008-5-5 14:41
一个好的开发人员不光要会写代码，还要对软件工程有较好的掌握，对于一个项目，如果没有文档积累下来，随着人员的流动，时间的推移，很难想象以后的代码维护要怎么做，再说，把一件事情做的流程化，有条理，与人方便也是给自己方便。
至于楼主对qa的不满，想必还是对这个行业不了解，不妨虚心学习一下，也长长自己的见识。
良好的沟通也很重要。仇视的心理也要不得。
tye 2008-5-5 21:41
那时因为印度IT做的成熟,他们的风格都是一样的,不像中国开发人的随性.说到底是因为在学习编码时没有学好编码规范,代码的规范化太重要了!
luoyear 2008-5-6 07:55
QA也有问题，现在很多QA不懂项目管理，不懂研发和业务。虽然监控，推行甚至审核着过程，却不知道当前最适合的是什么样的过程，为什么要这样做。
mustxc 2008-5-6 09:06
也说两句
个人觉得，完全没有必要以完全的开发人员的角度来衡量QA的工作，也没有理由全盘的以QA的工作性质来约束开发。这不是单纯的某个人的问题，某个项目的问题，某个公司的问题。而是沟通的问题，理解的问题，流程化的问题，在实际的项目工作中，更是些说不清道不明的问题。我的观点是，不要刻意的去解析出责任出自谁，而是为什么会出现这样的问题，我们如何可以有效的避免类似问题。对于一个成熟的工作体系而言，任何的工作步骤都会有条理的，有规律的进行，无论是PP、RD、CM、VER、VAL都绝对不是单单的概念性的问题，而的确是项目科学化，合理化进程的有利依据。可为什么我们的开发人员会对QA反感呢？为什么会觉得文档规范化无意义呢？为什么会觉得QA是个找别扭可有可无的虚职呢？这里不能一味的指责开发人员的态度问题，无项目大局观，从行业的特点而言，同公司的氛围来讲，这是一种惯性的思维方式。无疑这些对他而言无技术含量的文字是不能引起他的兴趣的，而且还严重的影响了自己的正常工作。那么QA的工作失职？的确QA有其工作不变通的一面，技术薄弱的一面。而公司有定位好他们过CMMI3的目的吗？PM可能抱怨比这位仁兄更多吧。甚至于客户的因素也不能回避吧。
maomao257 2008-5-6 10:02
LZ首先要明确QA工作的性质,然后在QA的角度来衡量下他们的工作, 要学会站在别人的角度看问题. 还有出现问题别都一古子的推卸责任,要敢于承担
anny_lv 2008-5-6 10:21
[quote]原帖由 [i]luoyear[/i] 于 2008-5-6 07:55 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=962134&ptid=113146][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
QA也有问题，现在很多QA不懂项目管理，不懂研发和业务。虽然监控，推行甚至审核着过程，却不知道当前最适合的是什么样的过程，为什么要这样做。 [/quote]
这个问题我也想说说看法：
1.不是为了过CMMI3才设立QA的职位，我公司就是为了过CMMI3设立了QA职位。
2.QA必须具备什么样的条件才能担任？
回答完第二个问题我相信楼主应该知道不能一杆子打死所有的QA。
问题不是出在QA身上，而是出在公司管理层定位的问题上。
我引用的话正说明了这点：
不懂研发，如何对代码进行验证？不懂只能说是把代码下下来，F5一下，看是否报错，再检查一下代码是否安公司要求进行代码规范。这样的工作很死板。
不懂业务，那更让人头大了，项目的需求分析评审怎么办？
现在有多少公司能正确定位QA的职务？
问题不在个人，而在公司！领导垃圾员工受罪！
zhzh1111 2008-5-6 13:21
开发测试本一家 目的只是为了一个：做质量最好的软件 然后卖了 大家一起拿工资 这不OK了
bettyZhu 2008-5-6 14:20
LZ公司的QA不错了，项目有错了还不用挨骂，挨，可怜我在以前的公司又是Tester又当QA的。。项目忙的时候，恨不的分身来做，忙中总会出错的。。可惜，我们公司的是项目有问题，都是QA的错，是QA没有把好质量关，挨，，可怜，老是挨骂。
muerte 2008-5-6 14:28
嘿嘿,按照lz这么说,你们公司的测试人员水平可能不是你想像中那样厉害,毕竟测试和开发关注的东西不一样,我们公司,基本上都要写应用程序测试公司的产品,请问,这样的测试人员会不会比你们公司开发人员厉害呢! 其实,厉害的测试牛人,绝对是一个领域的专家,而且编码能力,绝对的强悍,只是你没有遇到过而已
duhongze 2008-5-6 14:42
回复 10# 的帖子
说的好 ！！:handshake
li_lisa668 2008-5-6 14:43
工作中總是存在很多不如意的地方，我們公司也是這樣。個人覺得這個問題最終還是人的因素，關鍵在與溝通、協調。現在很多公司的流程管理都不正規，所以不能總是抱怨，而是要想辦法解決問題才是正確之道。
liaoxj 2008-5-6 15:11
楼主可能对QA工作有误解！
首先QA主要是对项目过程进行跟踪，他不一定有很好的业务知识，但是对项目过程进行监督。他是来规范咱们项目流程的，说得通俗点就是来帮我们的！即然你们公司已经过了CMMI3那项目过程应该有一定的规范！
举个简单例子，比如详细设计阶段，QA关注的是有没有评审，评审过程中有问题有没有解决，评审通过以后配置管理员有没有纳入基线！
最后要说明你写的详细设计说明书不是写给QA的，而是写给编码人员看，如果你写的详细设计如果100个写代码，会出现100个版本，这说明你写详细设计的水平很烂，你到底有没有能力做设计，你的工作能力和态度都需要打？？？？？？？？？？？？？？？？？？？
bwg198411 2008-5-6 16:32
:D 仔细看我了每个人的回复 学到好多