51Testing软件测试论坛

标题: 测试部门如何分工、测试部门需不需要做版本控制 [打印本页]
作者: sixsigmay    时间: 2008-8-22 16:13
标题: 测试部门如何分工、测试部门需不需要做版本控制
我所在的测试部门只做功能性测试，测试部门并不正规。在这边工作了一段时间后，碰到了一些问题。因为我刚从学校毕业，在学校里也系统学习过测试方面的知识，所以在工作中经常反省部门与理论中的矛盾与结合点。
    碰到了以下几个问题：
一、------------------------------------------------------------------------------------------------------------------------------
贵公司的测试部门是如何进行分工的？   
    部门里没有明确分工。组长+测试人员。组长接下需求后发给某个空闲的测试人员，然后测试人员就开始研究需求，写场景，执行，跟踪bug等到最后执行完成。。在这样的模式下，结合碰到的问题，我总结一下
        （1）让新人直接来写场景，虽然新人去了解熟悉场景
             ------个人认为，写用例（场景）也是一个经验活，新人花时间去写场景，就算写得好，但是时间也浪费很多。可是经验活的事情，新人花时间去熟悉场景了，也一定能写得好吗。
        （2）一个人写好了场景后直接发给需求方和开发方要求review，但是需求方和开发方是否真正review过，谁都不知道，我碰到的问题就是他们没有review过，后来在测试的时候就让我修改场景，增添场景。
             ------个人认为，场景写好后是应该进行测试组内部员工的review的。可是同事不然！！！认为找内部人员review，会花费很多时间，如果别人忙怎么办。同事建议说还不如自己拿到需求后好好去熟悉，然后写场景。可是，我想就算一个人能力再强，熟悉需求再透彻，也会有疏忽掉的地方。
        碰到这些问题后，我在想，别的公司是如何来做分工的呢，，，如何来避免写的场景不完整呢，如何分工可以使得测试组工作效率更高呢！！很想听听达人们的意见，非常感谢。
二、---------------------------------------------------------------------------------------------------------------------------------
    测试部门的版本控制是做哪些内容。。
    在对版本控制模糊的情况下，我学习了VSS版本控制的工具，但是学习后我不清楚该工具怎么用在测试部门上。后来和一些开发人员交流后惊讶发现自己的无知，原来VSS子类的一些版本控制工具在研发上是非常有作用的，用得也非常普及。。那么这个时候我迷糊了，到底测试部门要不要做版本控制，如果要做，做的是哪些内容。
-------------------------------------------------------------------------------------------------------------------------------------
    简要说了一下在工作中碰到的这两个问题，希望能够有经验的朋友给予建议与指导。
    非常感谢，因为刚从学校到公司实习，我也酷爱测试，希望问题可以得到大家的帮助，谢谢！
----补充第三个问题，谢谢大家给予的建议，谢谢
三、--------------------------------------------------------------------------------------------------------------------------------
    如何推行bug跟踪管理系统，在这个过程中个人需要掌握的资料以及能力
    来到部门后，在工作中发现，在对场景进行执行的过程中，bug没有一个规范的跟踪管理过程。我们这边的测试执行是这样来做的：该场景负责人TESTER测试后发现bug，联系该bug相关模块的负责人DEV，告诉bug信息，然后DEV去解决。解决后呢TESTER再测。。。其实这样说这个过程时倒没发现大问题，但是实践中，我个人发现以下几个问题：
    1.一个bug表现表现的错误是找DEV_A,然后tester报告bug给DEV_A，DEV_A查bug后说需要找DEV_B来解决，然后tester又把bug报告给DEV_B-----我就碰到这样的过程，3个模块开发方来解决这个问题，后来达不成统一，又让tester找模块总负责人，后来模块总负责人认识到这个问题，说他来组织解决。。花了tester很多无用功。。虽然问题解决了，但是觉得如果模块开发方内部讨论解决时，会更有效更开。
    2.bug提交给开发方后，因为是在QQ上报告错误的，没有bug管理系统来记录管理bug，开发方一忙起来会忘记曾在QQ里报告给的bug。很多时候bug解决被耽搁下来，效率不高
   3.------
   到公司上班的这一段过程，觉得很有必要有一个bug管理系统来管理测试执行过程。。如果有bug管理系统，那么tester工作职责明确，提交bug信息后，解决过程就交给开发人员，第一个问题就不会出现在tester身上。。有了bug管理系统后，每个开发人员都可以实时关注系统上分配给自己的错误，不会像QQ聊天记录上那么乱，也不至于忘记掉。
   所以个人就倒弄BUGFREE，可是在想，个人学习了仅仅一个bug系统可不够。。。。如何来推行这样的bug管理系统。。。在这个过程中，我需要更多掌握哪些技能和知识。。
-------------------------------------------------------------------------------------------------------------------------------------

谢谢大家的积极讨论，非常感谢！！

[ 本帖最后由 sixsigmay 于 2008-8-29 11:28 编辑 ]
作者: sixsigmay    时间: 2008-8-22 16:35
每天都会关注这个帖子，希望大家给予建议，欢迎讨论
作者: ccn8881933    时间: 2008-8-22 17:43
新人一般都要需要一段时间来了解系统与产品的，直接参于用例的编写，不见得会有好的效果，可以在熟悉产品后再介入用例的编写。
对于第二个子问题，解决办法是评审会的召开。可以招开同行评审，让开发与测试及相关人员参于测试用例的评审。
作者: kiss0710    时间: 2008-8-22 18:32
问题一:测试任务来后，我们也是一样，给leader.然后leader挑选他认为可靠的人，看PRD,DFS,然后写用例,即使有review过，我也碰到过被要求添加用例的情况(你说的场景是不是feature啊?迷惑),客户最大,没办法.我也不敢像老员工一样,直接质问客户的大脑呵呵~

问题二:我们测试的版本就是开发那里拿过来的，配置工程师Build好以后,传给我们测试,然后,发现bug.修复后,又把这个Build merge到主线上.所以我们部门没有自己做版本控制,有的公司测试部也有自己做版本控制,具体作用是什么我也不知道.帮不了你.哪位同学的公司有，分享一下哈.
作者: general82    时间: 2008-8-23 17:31
我们公司测试在分工上也不是很多角色，基本也是组长加测试人员，但是有一点，无论是组长还是测试人员对于自己负责的系统和需求都很明确，这个需要在前期花一定的工夫，比如所测试系统的培训，需求的分析等等，测试组长不是单纯的分配任务就可以了的，他还需要做很多事情，不能仅仅叫空闲的测试人员去直接开发场景的，他自己页一定要明确所测试的场景如何组织，不能直接叫新人去开发场景，更不能撒手不管了。
测试人员开发好测试用例（也可以说是场景）首先需要组长review的，不是直接找开发和需求方，这个控制场景的完整性实际上就落实在组长身上。所以说，组长要事必躬亲的。
作者: lotuis    时间: 2008-8-23 21:10
场景？是测试用例吧，Test Case？

一般来说，正规点的项目都会有文档的，文档有好多种，比如测试方案，测试文档，设计文档，等等，根据文档写出基本的cases，然后再根据自己的理解和经验添加cases，比如按照最终用户的眼光，还有哪些问题需要考虑的；和竞争对手的同类产品相比，有哪些劣势，等等等等。

至于测试部门的版本控制，一般除了被测对象的版本控制，比如daily build之类，只有自动化测试代码需要版本控制，其他貌似没有需要进行版本控制的地方了，而且，只有自动化测试代码的版本控制才是需要Tester直接处理的，大一点的公司，都会让软件配置管理人员进行版本控制，不需要Tester操心的。
作者: shunfyu    时间: 2008-8-23 23:38
版本控制也叫CM。 这应该是开发人定义好了的~~~
作者: photon    时间: 2008-8-24 22:57
1。关于Review
让review的人给出一个review report，这个活动应当得到测试组长的支持。如果reviewer拖延，则需要经常督促，如果reviewer不愿写report，通过沟通了解原因，但是要注意，这份report不应该成为日后拒绝修改测试场景的理由，不要抵制变更，而是要促进变更较早的暴露出来。

2。关于配置管理工具
测试人员同样需要掌握这类工具。理由也简单，既然你要不停的变更，就要有一个追踪变更的工具。同时也能解决一些误操作的问题。
作者: sixsigmay    时间: 2008-8-25 09:40
？我这个问题提问得错误么，怎么没有人回答的
作者: sixsigmay    时间: 2008-8-25 12:24
原帖由 kiss0710 于 2008-8-22 18:32 发表
问题一:测试任务来后，我们也是一样，给leader.然后leader挑选他认为可靠的人，看PRD,DFS,然后写用例,即使有review过，我也碰到过被要求添加用例的情况(你说的场景是不是feature啊?迷惑),客户最大,没办法.我也不敢像 ...

朋友口中说的review，是如何review的，，能否稍微详细告之。。客户会要求修改倒无所谓。。就是想知道如何来安排review。
作者: sixsigmay    时间: 2008-8-25 12:25
原帖由 general82 于 2008-8-23 17:31 发表
我们公司测试在分工上也不是很多角色，基本也是组长加测试人员，但是有一点，无论是组长还是测试人员对于自己负责的系统和需求都很明确，这个需要在前期花一定的工夫，比如所测试系统的培训，需求的分析等等，测试组 ...

嗯，觉得测试组长来做场景review会不会不实际。。测试组长不会做这个事情吧，应该没有这个时间。。
作者: sixsigmay    时间: 2008-8-25 12:31
原帖由 lotuis 于 2008-8-23 21:10 发表
场景？是测试用例吧，Test Case？

一般来说，正规点的项目都会有文档的，文档有好多种，比如测试方案，测试文档，设计文档，等等，根据文档写出基本的cases，然后再根据自己的理解和经验添加cases，比如按照最终用 ...

嗯是的，我说的场景就是test case，呵呵
嗯是的，我们这边拿到任务时也有这些文档。。。在写场景之前我们接到任务的那个同事都会认真去了解需求和其他文档，，，我部门这边的情况是，写好场景后，同事和开发方、需求方联系，把场景发过去后要求review，可是觉得开发方和需求方并不会去做这个事情。。然后我想呢，在发这个无所谓的review邮件之前，，是不是应该测试组里有内部review这个过程。。。我很想听取下朋友们的公司是如何进行这个步骤的，，，和我们一样不需要经过内部review，，还是有一个规范的过程进行内部review。
作者: lotuis    时间: 2008-8-25 13:00
原帖由 sixsigmay 于 2008-8-25 12:31 发表

嗯是的，我说的场景就是test case，呵呵
嗯是的，我们这边拿到任务时也有这些文档。。。在写场景之前我们接到任务的那个同事都会认真去了解需求和其他文档，，，我部门这边的情况是，写好场景后，同事和开发方、需 ...

我接触过的项目从来没有Review，都是直接自己写了Case就结束了，产品已经拆分为一块一块了，一个人负责一块或几块，这个人就是这块的Owner。
只有每次需要执行Test Pass的时候，或者非Owner添加别人所属模块的Cases才可能需要Owner来review，其他基本没有过，不过我所在的公司只做产品，不做项目，所以没有确切的客户一说，所以可能和你的理解有些差异。
作者: sixsigmay    时间: 2008-8-25 13:25
原帖由 lotuis 于 2008-8-25 13:00 发表

我接触过的项目从来没有Review，都是直接自己写了Case就结束了，产品已经拆分为一块一块了，一个人负责一块或几块，这个人就是这块的Owner。
只有每次需要执行Test Pass的时候，或者非Owner添加别人所属模块的Cas ...

嗯，明白了，其实你那边的做法和我这边的差不多，就是一个人负责一个完整的测试，场景自己写，测试自己做等等。。lotuis，这样的模式会不会觉得一个人写的测试不够完整或者觉得有没有别的好的测试分工的。把测试的各个步骤分成一块块来做，生产流水线一样的模式
作者: lotuis    时间: 2008-8-25 15:24
原帖由 sixsigmay 于 2008-8-25 13:25 发表

嗯，明白了，其实你那边的做法和我这边的差不多，就是一个人负责一个完整的测试，场景自己写，测试自己做等等。。lotuis，这样的模式会不会觉得一个人写的测试不够完整或者觉得有没有别的好的测试分工的。把测试的 ...

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

多嘴一句，case千万别什么都往里面写，虽说要把最容易出问题的场景都给列出为case，但是为了个人考虑，不要写的太细，所谓的标准化乃至CMM，Agile之类，无非就是剥离人的差异价值，你把该列的case都列出来了，换个人直接就能顶替你，但是如果你留点不容易想到，但是经常出bug的场景在心里，测试的时候就出bug，平常的时候就装不知道。

我不是教你使诈，只是要保护自己，测试这一行很容易混，什么人都有，一些灵光一闪的漂亮case就是你的价值，除此之外还有什么能让自己闪光的？尤其对于你这样的新人。在公司规定和领导允许的范围内，能让case越难读越好，除了你什么人都看不懂，需要执行就要问你，我经历过的项目都是这样，不管是印度人，还是美国人，都是私下里加门槛，跑对方的case，必须问他怎么跑才知道如何执行，换个人，就算看文档也不一定明白，举个例子，问你哪两个数相加等于2，只回答1＋1，还问，才说2＋0，自己要做了，才把3＋（－1）之类拉出来，这样你对公司才有价值，比如能不写case的步骤，就不写，能用项目特定术语的，就用术语，能用简称的就用简称。还有不管什么公司，只要有tester，潜意识里都是把bug数量当作衡量其实力的标杆，不管bug如何垃圾，你报了10个垃圾bug，绝对比只报1个超牛Xbug的牛人要受老板赏识....
作者: archonwang    时间: 2008-8-26 09:35
本帖稍后关注。
作者: sixsigmay    时间: 2008-8-26 15:49
原帖由 lotuis 于 2008-8-25 15:24 发表

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

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


非常感谢指导，嗯继续学习，继续关注
作者: lovsnow    时间: 2008-8-26 17:39
原帖由 lotuis 于 2008-8-25 15:24 发表

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

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


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


我们也是由组长分配各个项目给组员，当然会给很详细的需求文档，然后该组员先写测试计划，写好后由组内进行评审，将遗漏的地方进行补充（我们的测试计划是针对自己内部的，其中包含测试要点）。对于测试用例，到是很少进行很完整的评审，因为太多了，没有那么多的时间、精力。主要由组长在测试的过程中进行一些相关容易遗漏的东西的补充。
作者: code727    时间: 2008-8-27 10:44
1.新人写用例是可以,就当让他们学习写用例的技巧,同时也熟悉了需求,但负责人不一定要采纳他们的.
2.测试组长对版本控制是很重要的,如果不做这项工作的话,会有很多麻烦的.比如说版本发布后,就不能再让开发人员到测试系统上改东西了.我曾经遇到一个很严重的问题,比如说我到V1.0版本上测试发现了一个BUG,由于我没加版本号,他们开发的由于在开发V2.0,就没有回现你在V1.0版本上发现的BUG,这样我的工作就算是白做了.所以后来我就认识到必须要有版本控制的意思.
3.关于版本控制还需要配置和项目经理来共同维护,虽然这样做可能会增加成本,但质量才会有保证.
作者: archonwang    时间: 2008-8-27 12:59
呵呵，楼主如果是测试部门负责人的话，估计要有好多工作呢。。。
简单就楼主的一些问题做个回答，抛砖引玉下。




讲到具体的测试执行工作，那没什么太多的技巧，扎扎实实才是王道。是否对需求有疏漏，取决于是否有进行具体的分析，是否有可靠的追踪数据，是否能得到有效的确认，而不是个人能力的问题。一个新手接手一个项目的需求，都是从不了解到了解的过程，几乎没什么区别，区别在于工作的方式方法是否正确，之前的准备工作是否妥善完备，之后的检查工作是否到位而已。至于说到如何高效，这里工作的方向和方法可能是决定性的因素，需要摸索工作方法，提升效率，并不断优化这种方法，直到更高效率而已。所以，想问问楼主如何做测试需求分解的，怎样跟踪测试需求变更等这一系列的问题，否则，实难说明。

具体的发布工作可以请开发团队开发工作或编写脚本完成，QA团队更多地应关心是否已经按流程做了对应的工作，每个步骤是否都检查到了。

希望以上这些可以提供给你帮助。

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

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


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


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

模式和我的倒不多，就是测试计划这一块，好像我到现在还没有真正写过，虽然在2个月内已经有过从开始接需求做测试到完成整个完整的过程，可是发现测试计划在我们组里并不重视。。。嗯，能听听你的意见吗，在测试计划这一块。。。非常谢谢你的留言，希望能够多指教
作者: sixsigmay    时间: 2008-8-27 14:43
进来看过这个帖子的朋友，帮忙把帖子顶起来好吗，非常感谢
作者: mayan6656    时间: 2008-8-27 16:15
我现在正要往测试的行业里钻。
不过不是很明白，正常来说。
首先应该是BA做需求分析，资深的QA做test plan.
再做test plan之前就应该确保requirement 是准确无误的。
如果在做test case的时候修改requirement 是不是QA的失职吗？
作者: general82    时间: 2008-8-27 16:52
to 24#
      在做test case 的时候requirement是会经常变化的，这个不是谁谁谁的责任，关键在于有了变化需要及时调整测试用例，要做到测试用例的及时更新，有时候书本上说的不一定是标准
作者: general82    时间: 2008-8-27 17:05
to 楼主：

         看到你给我发的短消息了，也谢谢你的鲜花，你觉得测试组长做review行不通，这一点我说一下，其实每个公司的项目组结构都不是很相同，所以我说的可能是针对我所在的项目组，我所在的项目组是一个长期的项目，期间版本更迭是很频繁的，而且系统很庞大，所以测试组长也不能达到很了解所有项目的所有细节，要做到每个功能点测试用例都review是很困难的，但是这不代表我们就不做review了，分几种情况吧，
分几种情况
一，如果所涉及的模块测试组长比较清楚，需要review
二，如果所涉及的模块测试组长不清楚，需要由开发测试用例的人员向测试组长讲述需求，然后讲解测试用例，这个可能会花点时间，但是这个也是必须要做的，测试组长可以
考虑到测试用例的全面性，
三，可以做测试组同行评审，也是由测试组成员参加，共同review测试用例，
其实测试用例review是很好的一种方式，无论对于产品质量还是成员的个人能力提高，坚持做的话，测试用例的质量和全面性会得到很大的提高
作者: mayan6656    时间: 2008-8-28 08:17
那现在大家用的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    时间: 2008-8-28 08:45
欢迎大家踊跃发言呀，
作者: archonwang    时间: 2008-8-28 09:00
原帖由 sixsigmay 于 2008-8-22 16:13 发表
如何推行bug跟踪管理系统，在这个过程中个人需要掌握的资料以及能力
     ...


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

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



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



[ 本帖最后由 archonwang 于 2008-8-28 09:22 编辑 ]
作者: kiss0710    时间: 2008-8-29 08:46
原帖由 sixsigmay 于 2008-8-25 12:24 发表

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



不好意思，这几天被cluster给搞晕掉了,我们一般会给同事review下，看看有没有漏掉哪些需求,或者哪些应该更改下.然后leader会检查(会真的检查,如果我们做的不合格被骂的是他/她),然后扔给客户和开发方review,过几天再转回来,如果合格就按照这个执行,不合格就直接弃用了.我个人感觉大多数情况他们是不看的。因为执行别人的用例时会发现明显的不符合需求的情况.
作者: kiss0710    时间: 2008-8-29 09:03
原帖由 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    时间: 2008-8-29 09:11
原帖由 archonwang 于 2008-8-28 09:00 发表


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

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

TESTER查询问 ...

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


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

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

bug的标准这个得看你上司的偏好，特别是你的老板是新来的，你和Dev之间形成的bug默契，相关的人都知道是什么，但是他不知道，他就会如更年期一般指责你的bug不合规范，其实是他抛不开面子去问，低级种姓的黑皮肤印度老女人尤其如此。
作者: lotuis    时间: 2008-8-29 09:21
原帖由 kiss0710 于 2008-8-29 09:11 发表

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

没有正不正规的，如果非要按照国际标准，ISO9000，CMMI之类，你们都不正规，你们只是QE，汇报bug就是你们的职责，流程是由QA负责，你们一个是大QA制度，过程控制到质量检测全是QA，一个是没有QA，直接Tester与Dev直线联系，在像微软的流程里，还有Triage角色，就是替换你们系统自动assign的角色，他们负责bug的第一轮处理，比如优先级够不够啊之类。
作者: archonwang    时间: 2008-8-29 10:35
标题: 回复 32# 的帖子
如果公司规模不大，那差不多就是这样子啦。如果公司规模比较大，流程很规范，那么对应的各项工作都有一个角色进行支撑。若是说报上去不管，那么在大型公司里，就有对应的角色做分配、跟踪及报告通知的工作，在中小型的公司里，那可是工作不到位哦。关键还是看你在哪里，这个事情不算大，但是总归要有人负责做。没人做就得想办法解决，否则流程是不可能顺畅的——一是因为信息不对称，二是因为一些人为的沟通障碍。

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

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

[ 本帖最后由 archonwang 于 2008-8-29 10:42 编辑 ]
作者: sixsigmay    时间: 2008-8-29 11:06
原帖由 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    时间: 2008-8-29 11:17
    原帖由 kiss0710 于 2008-8-29 09:11 发表

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



    我就是希望有你这样的一个bug流程，，不是让测试人员来找问题的负责人，测试人员是负责找bug，提交bug后是应该让该bug模块负责人来分配问题和解决问题的吧。。。不知道我的是否对
    作者: kiss0710    时间: 2008-8-29 13:44
    原帖由 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    时间: 2008-8-29 16:30
    有很多缺陷管理工具可以用的啊我们公司用的是TD，感觉还好。发现bug后提交（填写版本号，具体问题，serverity，priority）给模块负责人，系统会自动发邮件给负责人的，然后他们修改后会修改bug状态为fix，然后tester在new version中verify，通过就close否则在reopen
    作者: zzy302    时间: 2008-8-29 17:05
    同意38 39楼的兄弟，我们有自己的一套bug管理系统，目前流程方面没有这么乱

    但是其他方面存在不少问题
    作者: havards    时间: 2008-9-1 16:33
    你们居然拿QQ来报告问题，真是太牛了！！！
    作者: 任道远    时间: 2008-9-2 16:08
    作者: dhy    时间: 2008-9-2 16:38
    一、缺陷管理系统
    我也是刚开始做测试，我们公司原来都没有测试组，我是新加的。呵呵所以关于测试的一切都是从头做起。我们的leader对于规范意识很强烈，所以成立测试组后第一步做得就是搭建了缺陷管理系统，我们用得是bugzilla，leader要求所有的开发人员也都熟悉下这个缺陷管理系统，以便可以随时查看报告给自己的问题，尽快的解决问题。我觉得这个缺陷管理系统还是很必要的，虽然现在对它的使用并不是很熟悉，但目前搭建它的意义大于使用，只有搭建好了才能慢慢熟悉使用。
    二、版本控制
    我们部门有对于版本控制的要求，只是刚工作还没使用过（我刚开始实习10天 ），也不知道如何使用，发布哪些内容呢，呵呵这方面以后学到了可以继续补充。
    三、bug报告
    由于我们部门比较小，所以还没有真正意义上的规范，对于发现的问题也是msn或QQ直接与相关的开发人员联系，不过我们会把所有的问题记录下来，然后汇总问题用邮件发送给开发的负责人员，抄送项目负责人。这样负责人也会关注这些问题的解决，有助于加快问题解决的效率
    呵呵在你的这个话题里学到很多东西，希望咱们共同进步！
    作者: msnshow    时间: 2008-9-13 13:35
    bug管理系统的好处不仅仅在于,在项目测试过程中的管理,还有利了经验的积累,当你完成一个项目后,再回去看自己所提交的BUG你会发现表述不清楚的地方之类的,在以后的项目中就能改进
    作者: sixsigmay    时间: 2008-9-26 10:57
    这段时间测试组很忙都没关注该主题，感觉到大家还是很热情的，给予我很多的建议，非常感谢
    作者: sixsigmay    时间: 2008-9-26 10:58
    原帖由 havards 于 2008-9-1 16:33 发表
    你们居然拿QQ来报告问题，真是太牛了！！！

    呵呵，测试组没有使用bug管理系统，都是测试中出现问题，测试员就直接QQ给问题负责人，然后沟通解决。
    作者: chillbin    时间: 2008-11-16 22:00
    受教了，学习中～～～～～·
    作者: 6739    时间: 2010-9-17 16:51
    学习了
    作者: wcp_856    时间: 2010-11-4 14:56
    版本管理工具是必须的，bug管理工具也是必须的，只是有些公司意识淡薄没有搞
    作者: Dangerous_1    时间: 2011-3-15 19:35
    回复 1# sixsigmay


        小公司的制度就是不规范啦
    作者: huazai_888    时间: 2011-5-17 22:35
    tks



    欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2