测试部门如何分工、测试部门需不需要做版本控制

lotuis

原帖由 code727 于 2008-8-27 10:44 发表
1.新人写用例是可以,就当让他们学习写用例的技巧,同时也熟悉了需求,但负责人不一定要采纳他们的.
2.测试组长对版本控制是很重要的,如果不做这项工作的话,会有很多麻烦的.比如说版本发布后,就不能再让开发人员到测试 ...

我不太明白你说的版本控制，对于很多公司来说，bug跟踪系统都有填写对应项目版本的选项，一般都是必填项。而且一些采用Water Fall模式的公司，Dev开发完之后才扔给Tester测试，当前测试版本只有一个，比如1.0，就算后续开发出2.0，测试的时候，肯定是当前版本优先，以前的版本忽视。

sixsigmay

原帖由 lovsnow 于 2008-8-26 17:39 发表


呵呵，看来是前辈的经验之谈啦，之前还真没想过这个问题。


我们也是由组长分配各个项目给组员，当然会给很详细的需求文档，然后该组员先写测试计划，写好后由组内进行评审，将遗漏的地方进行补充（我们的测 ...

模式和我的倒不多，就是测试计划这一块，好像我到现在还没有真正写过，虽然在2个月内已经有过从开始接需求做测试到完成整个完整的过程，可是发现测试计划在我们组里并不重视。。。嗯，能听听你的意见吗，在测试计划这一块。。。非常谢谢你的留言，希望能够多指教

sixsigmay

进来看过这个帖子的朋友，帮忙把帖子顶起来好吗，非常感谢

mayan6656

我现在正要往测试的行业里钻。
不过不是很明白，正常来说。
首先应该是BA做需求分析，资深的QA做test plan.
再做test plan之前就应该确保requirement 是准确无误的。
如果在做test case的时候修改requirement 是不是QA的失职吗？

general82

to 24#
      在做test case 的时候requirement是会经常变化的，这个不是谁谁谁的责任，关键在于有了变化需要及时调整测试用例，要做到测试用例的及时更新，有时候书本上说的不一定是标准

general82

to 楼主：

         看到你给我发的短消息了，也谢谢你的鲜花，你觉得测试组长做review行不通，这一点我说一下，其实每个公司的项目组结构都不是很相同，所以我说的可能是针对我所在的项目组，我所在的项目组是一个长期的项目，期间版本更迭是很频繁的，而且系统很庞大，所以测试组长也不能达到很了解所有项目的所有细节，要做到每个功能点测试用例都review是很困难的，但是这不代表我们就不做review了，分几种情况吧，
分几种情况
一，如果所涉及的模块测试组长比较清楚，需要review
二，如果所涉及的模块测试组长不清楚，需要由开发测试用例的人员向测试组长讲述需求，然后讲解测试用例，这个可能会花点时间，但是这个也是必须要做的，测试组长可以
考虑到测试用例的全面性，
三，可以做测试组同行评审，也是由测试组成员参加，共同review测试用例，
其实测试用例review是很好的一种方式，无论对于产品质量还是成员的个人能力提高，坚持做的话，测试用例的质量和全面性会得到很大的提高

mayan6656

那现在大家用的test methodology 是water fall 还是 interation？
所谓的business requirement的改变是相对整个develop team 的改变还是就是仅仅QA team的改变？
如果用interation 的话适当的改变应该比较正常，但是经常的改动应该是不是各个环节都有问题呢？
对了，还有相关于vison control 的问题应该是很严重的吧，每天每个PA的build都不一样，没有cm控制是会出大问题的。
相关document的建立应该也是必须的，相对于新进员工的培训也是很有用的。
比如如果新去一家公司上班，首先的是应该要求现项目的requirement review 其中应该包括business requirement analyst ，system specifiction，和requirement checklist。当然公司不同各种情况也会不一样。
其实我还是想了解一下大家的情况都是怎样的，比如说新员工上班和日常的工作流程。
这些比较有利于我编写简历，希望大家不吝赐教。

sixsigmay

欢迎大家踊跃发言呀，

archonwang

原帖由 sixsigmay 于 2008-8-22 16:13 发表
如何推行bug跟踪管理系统，在这个过程中个人需要掌握的资料以及能力
     ...

关于这个问题，简单说下自己的看法

    1.一个bug关联到好几个模块时，模块A_DEV说这个错误是模块B_DEV的，好，那我跑去问模块B_DEV-------会出现这样 的过程，让TESTER来找追寻问题原因。

• TESTER查询问题原因是对TESTER的能力要求，如果楼主尚不能很清楚系统的模块间关系及模块对应的负责人和系统接口，那么建议楼主好好研读相关的需求及设计文档。一个TESTER如果能很清楚的透过问题表象看到本质，很能说明一个TESTER的水平和能力及其对系统的熟悉程度。注意在培养这种能力的时候优先培养系统化的思维能力，能根据有限的资源，自主进行关联性（动态）分析，等经验做到了一定程度后，就事半功倍啦。
• 出现这种开发模块负责人不明确的情况，一般都是因为职责划分不明确所致的，普通的TESTER由于无法分析其内在关联关系，故不能准确定位，出现这种情况时，可以请求相关的开发组长，项目经理达成某种协议，碰到这种问题直接转交给主要负责人分配和解决。若出现争议，则直接在技术会议上讨论解决。

    2.DEV忙的时候，会忘记TESTER给他的BUG，然后TESTER一直等不到结果，去问他，他说，哦忘记了，有些时候还会问起，是什么错误。。GOD，去查聊天记录去，快点帮忙解决吧

• 很明显，团队内没有很好地形成一种及时反馈的机制。所以首先要建立一种机制。
• 其次，TESTER对于结果的要求很薄弱。我们一般都这样做，对于bug，分好类别后，对某一类的bug修复要求是在某个时间段内处理完毕。这个追踪可以由QA人员完成，也可以使用缺陷管理系统完成，但是必须要有，并且有人关心这些问题的最后处理结果！
• 在流程上，一般都会规避非正式的记录，尤其是你要求别人做的工作和别人要求你做的工作，必须正式并且让相关的直接领导知道该工作及其应该完成的时间。这样做一来可以明确职责，规避不应该承担的责任，二来也可以和上级加强联系。
• 最后一点，也是极其重要的一点，就是要把对应的考核加入到绩效考核体系中去，一个成熟的开发团队的基础是良好的沟通+明确的职责+流程与制度保障，我们可以从制度上对这种现象进行约束。

[ 本帖最后由 archonwang 于 2008-8-28 09:22 编辑 ]

kiss0710

原帖由 sixsigmay 于 2008-8-25 12:24 发表

朋友口中说的review，是如何review的，，能否稍微详细告之。。客户会要求修改倒无所谓。。就是想知道如何来安排review。

不好意思，这几天被cluster给搞晕掉了,我们一般会给同事review下，看看有没有漏掉哪些需求,或者哪些应该更改下.然后leader会检查(会真的检查,如果我们做的不合格被骂的是他/她),然后扔给客户和开发方review,过几天再转回来,如果合格就按照这个执行,不合格就直接弃用了.我个人感觉大多数情况他们是不看的。因为执行别人的用例时会发现明显的不符合需求的情况.

kiss0710

原帖由 lotuis 于 2008-8-25 15:24 发表

很多公司都是Water Fall的模式，比如微软，不过因为文档相对比较全，所以只要按照文档的范围去写case就可以了，只要覆盖了文档规定的内容，那就是没有问题的。

多嘴一句，case千万别什么都往里面写，虽说要把最 ...

恩，终于明白了，为什么我跑印度人的脚本时老觉得我自己智商低下呢，原来如此，谢谢～

插一句，我觉得国内的测试人员都太严格按照标准来了，举个例子，关于bug的书写规范，明明定好的标准，我们就傻傻的一步步按标准来，他们就直接一句话："Ｉdon't  think this issue need repeat steps, for detail, see my attachment".结果呢，我们做CR Verification 的时候，一个bug的重现还要发好几封邮件过去，末了还要被人说我们效率低，严重不爽中．

kiss0710

原帖由 archonwang 于 2008-8-28 09:00 发表


关于这个问题，简单说下自己的看法

    1.一个bug关联到好几个模块时，模块A_DEV说这个错误是模块B_DEV的，好，那我跑去问模块B_DEV-------会出现这样 的过程，让TESTER来找追寻问题原因。

TESTER查询问 ...

请教下：你们Bug提交上去以后还要自己去跟踪乃至直接找开发人员解决啊？我们都是报上去就不怎么管了，然后系统会自动assign给相应的developer．我们只要关注这个CR的状态就好了，不同优先级的ＣＲ都有一个解决的时间限制．所以到时候只要看解决没就好了．
哪种工作方式是比较规范的啊，请赐教．

lotuis

原帖由 kiss0710 于 2008-8-29 09:03 发表


恩，终于明白了，为什么我跑印度人的脚本时老觉得我自己智商低下呢，原来如此，谢谢～

插一句，我觉得国内的测试人员都太严格按照标准来了，举个例子，关于bug的书写规范，明明定好的标准，我们就傻傻的一步步 ...

bug的标准这个得看你上司的偏好，特别是你的老板是新来的，你和Dev之间形成的bug默契，相关的人都知道是什么，但是他不知道，他就会如更年期一般指责你的bug不合规范，其实是他抛不开面子去问，低级种姓的黑皮肤印度老女人尤其如此。

lotuis

原帖由 kiss0710 于 2008-8-29 09:11 发表

请教下：你们Bug提交上去以后还要自己去跟踪乃至直接找开发人员解决啊？我们都是报上去就不怎么管了，然后系统会自动assign给相应的developer．我们只要关注这个CR的状态就好了，不同优先级的ＣＲ都有一个解决的时 ...

没有正不正规的，如果非要按照国际标准，ISO9000，CMMI之类，你们都不正规，你们只是QE，汇报bug就是你们的职责，流程是由QA负责，你们一个是大QA制度，过程控制到质量检测全是QA，一个是没有QA，直接Tester与Dev直线联系，在像微软的流程里，还有Triage角色，就是替换你们系统自动assign的角色，他们负责bug的第一轮处理，比如优先级够不够啊之类。

archonwang

如果公司规模不大，那差不多就是这样子啦。如果公司规模比较大，流程很规范，那么对应的各项工作都有一个角色进行支撑。若是说报上去不管，那么在大型公司里，就有对应的角色做分配、跟踪及报告通知的工作，在中小型的公司里，那可是工作不到位哦。关键还是看你在哪里，这个事情不算大，但是总归要有人负责做。没人做就得想办法解决，否则流程是不可能顺畅的——一是因为信息不对称，二是因为一些人为的沟通障碍。

至于规范与否，我觉得没有必要深究，如果这种方式能很大程度上提高生产力，即使现在不规范也很快会变成规范的。我觉得仅仅是一种状态而已。

老实说，工业化生产的特点之一就是流水化操作，但是，流水化操作的前提之一就是所有的工作都可以清晰表述，都有人负责，都有参考依据，连贯性，没有缺失的任何一环。否则流程上出问题，必然影响后面的工序。大型公司和中小型公司由于在规模上的差异，导致了其管理问题本质上的不同。

[ 本帖最后由 archonwang 于 2008-8-29 10:42 编辑 ]

sixsigmay

原帖由 archonwang 于 2008-8-28 09:00 发表


关于这个问题，简单说下自己的看法

    1.一个bug关联到好几个模块时，模块A_DEV说这个错误是模块B_DEV的，好，那我跑去问模块B_DEV-------会出现这样 的过程，让TESTER来找追寻问题原因。

TESTER查询问 ...

    恶魔，你建议得非常正确，谢谢！！
    对于第一个问题，测试人员是应该对整个系统，或者是说对模块间的联系要熟悉。对于我现在处在的团队来说或者是不管在有没有bug跟踪管理系统的团队中，对于tester都是需要去理解和把握系统的全局，对系统的整体有个认识与熟悉。。我也正是在慢慢的熟悉测试的系统。。
    但是，我认为，，在tester提交bug后，bug的解决过程是应该交给开发方或者可以说是交给解决问题的团队，如果有bug管理系统，tester提交bug后由开发方组长来分配错误给某人，然后由某开发人员来解决bug，这解决过程是不应该tester来掺和的吧。（呵呵，是不是这样的。刚自学bug管理系统，不是很清晰）
    虽然在我测试部门里，找解决问题的人一般都能够及时准确找到并解决，但是就像我刚在帖子上说的，，如果又碰到了这样的情况---bug表面显示是DEV_A负责的，然而DEV_A在解决的过程中发现另外一个隐藏问题，需要DEV_B来解决，然后和tester说，这个问题需要去找DEV_B。好，tester去找DEV_B，然后和DEV_B说问题原因，说问题经过----那么，如果DVE_B发现需要找DEV_C来解决呢，那完蛋了。。tester有没有这么多的时间耗着。。。
    像我一次碰到的问题就是，，一个字段的问题，涉及到“产品组，，模块1开发组，模块2开发组”，产品组说需要模块1人员解决，模块1说不是的，这个字段***，好，又让tester去找模块2，模块又***！！！这个过程，我打了好多电话，，最后没有办法，只有打到模块总负责人那里，总负责人说，他来召集大家解决这个问题。。。花了很多时间，，所以，想到这个问题时，我就在想，是不是该推行bug管理系统了。
     所以个人想学习bug管理系统后，能够把系统推广。。所以发帖子征求大家的意见，，我该怎么做好这一块bug管理系统的内容。。

[ 本帖最后由 sixsigmay 于 2008-8-29 11:13 编辑 ]

sixsigmay

原帖由 kiss0710 于 2008-8-29 09:11 发表

请教下：你们Bug提交上去以后还要自己去跟踪乃至直接找开发人员解决啊？我们都是报上去就不怎么管了，然后系统会自动assign给相应的developer．我们只要关注这个CR的状态就好了，不同优先级的ＣＲ都有一个解决的时 ...

我就是希望有你这样的一个bug流程，，不是让测试人员来找问题的负责人，测试人员是负责找bug，提交bug后是应该让该bug模块负责人来分配问题和解决问题的吧。。。不知道我的是否对

kiss0710

原帖由 sixsigmay 于 2008-8-29 11:17 发表



我就是希望有你这样的一个bug流程，，不是让测试人员来找问题的负责人，测试人员是负责找bug，提交bug后是应该让该bug模块负责人来分配问题和解决问题的吧。。。不知道我的是否对

我公司是这样的,提交BUG的时候，你只要写清楚出问题的component是哪个,以及测试的版本号等必填问题就可了,然后每个component至少有一个developer负责,你提交后，这个BUG只要被CCB标注为Approved后,你就不用管了.直到这个问题Resolved了, 你再在新build上verify,没问题后你把这个BUG标记为Closed. 整个过程就是这样.但是不一定是谁报的CR就让谁Close.看你被分到哪个任务了。


你们上班都可以上网么,我们中午只有一个小时可以上.

qdd6501

有很多缺陷管理工具可以用的啊我们公司用的是TD，感觉还好。发现bug后提交（填写版本号，具体问题，serverity，priority）给模块负责人，系统会自动发邮件给负责人的，然后他们修改后会修改bug状态为fix，然后tester在new version中verify，通过就close否则在reopen

zzy302

同意38 39楼的兄弟，我们有自己的一套bug管理系统，目前流程方面没有这么乱

但是其他方面存在不少问题