测试部门如何分工、测试部门需不需要做版本控制
我所在的测试部门只做功能性测试，测试部门并不正规。在这边工作了一段时间后，碰到了一些问题。因为我刚从学校毕业，在学校里也系统学习过测试方面的知识，所以在工作中经常反省部门与理论中的矛盾与结合点。碰到了以下几个问题：
一、------------------------------------------------------------------------------------------------------------------------------
贵公司的测试部门是如何进行分工的？
部门里没有明确分工。组长+测试人员。组长接下需求后发给某个空闲的测试人员，然后测试人员就开始研究需求，写场景，执行，跟踪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 编辑 ] 每天都会关注这个帖子，希望大家给予建议，欢迎讨论:hug: 新人一般都要需要一段时间来了解系统与产品的，直接参于用例的编写，不见得会有好的效果，可以在熟悉产品后再介入用例的编写。
对于第二个子问题，解决办法是评审会的召开。可以招开同行评审，让开发与测试及相关人员参于测试用例的评审。 问题一:测试任务来后，我们也是一样，给leader.然后leader挑选他认为可靠的人，看PRD,DFS,然后写用例,即使有review过，我也碰到过被要求添加用例的情况(你说的场景是不是feature啊?迷惑),客户最大,没办法.我也不敢像老员工一样,直接质问客户的大脑呵呵~
问题二:我们测试的版本就是开发那里拿过来的，配置工程师Build好以后,传给我们测试,然后,发现bug.修复后,又把这个Build merge到主线上.所以我们部门没有自己做版本控制,有的公司测试部也有自己做版本控制,具体作用是什么我也不知道.帮不了你.哪位同学的公司有，分享一下哈. 我们公司测试在分工上也不是很多角色，基本也是组长加测试人员，但是有一点，无论是组长还是测试人员对于自己负责的系统和需求都很明确，这个需要在前期花一定的工夫，比如所测试系统的培训，需求的分析等等，测试组长不是单纯的分配任务就可以了的，他还需要做很多事情，不能仅仅叫空闲的测试人员去直接开发场景的，他自己页一定要明确所测试的场景如何组织，不能直接叫新人去开发场景，更不能撒手不管了。
测试人员开发好测试用例（也可以说是场景）首先需要组长review的，不是直接找开发和需求方，这个控制场景的完整性实际上就落实在组长身上。所以说，组长要事必躬亲的。 场景？是测试用例吧，Test Case？
一般来说，正规点的项目都会有文档的，文档有好多种，比如测试方案，测试文档，设计文档，等等，根据文档写出基本的cases，然后再根据自己的理解和经验添加cases，比如按照最终用户的眼光，还有哪些问题需要考虑的；和竞争对手的同类产品相比，有哪些劣势，等等等等。
至于测试部门的版本控制，一般除了被测对象的版本控制，比如daily build之类，只有自动化测试代码需要版本控制，其他貌似没有需要进行版本控制的地方了，而且，只有自动化测试代码的版本控制才是需要Tester直接处理的，大一点的公司，都会让软件配置管理人员进行版本控制，不需要Tester操心的。 版本控制也叫CM。 这应该是开发人定义好了的~~~ 1。关于Review
让review的人给出一个review report，这个活动应当得到测试组长的支持。如果reviewer拖延，则需要经常督促，如果reviewer不愿写report，通过沟通了解原因，但是要注意，这份report不应该成为日后拒绝修改测试场景的理由，不要抵制变更，而是要促进变更较早的暴露出来。
2。关于配置管理工具
测试人员同样需要掌握这类工具。理由也简单，既然你要不停的变更，就要有一个追踪变更的工具。同时也能解决一些误操作的问题。 ？我这个问题提问得错误么，怎么没有人回答的 原帖由 kiss0710 于 2008-8-22 18:32 发表 http://bbs.51testing.com/images/common/back.gif
问题一:测试任务来后，我们也是一样，给leader.然后leader挑选他认为可靠的人，看PRD,DFS,然后写用例,即使有review过，我也碰到过被要求添加用例的情况(你说的场景是不是feature啊?迷惑),客户最大,没办法.我也不敢像 ...
朋友口中说的review，是如何review的，，能否稍微详细告之。。客户会要求修改倒无所谓。。就是想知道如何来安排review。 原帖由 general82 于 2008-8-23 17:31 发表 http://bbs.51testing.com/images/common/back.gif
我们公司测试在分工上也不是很多角色，基本也是组长加测试人员，但是有一点，无论是组长还是测试人员对于自己负责的系统和需求都很明确，这个需要在前期花一定的工夫，比如所测试系统的培训，需求的分析等等，测试组 ...
嗯，觉得测试组长来做场景review会不会不实际。。测试组长不会做这个事情吧，应该没有这个时间。。 原帖由 lotuis 于 2008-8-23 21:10 发表 http://bbs.51testing.com/images/common/back.gif
场景？是测试用例吧，Test Case？
一般来说，正规点的项目都会有文档的，文档有好多种，比如测试方案，测试文档，设计文档，等等，根据文档写出基本的cases，然后再根据自己的理解和经验添加cases，比如按照最终用 ...
嗯是的，我说的场景就是test case，呵呵
嗯是的，我们这边拿到任务时也有这些文档。。。在写场景之前我们接到任务的那个同事都会认真去了解需求和其他文档，，，我部门这边的情况是，写好场景后，同事和开发方、需求方联系，把场景发过去后要求review，可是觉得开发方和需求方并不会去做这个事情。。然后我想呢，在发这个无所谓的review邮件之前，，是不是应该测试组里有内部review这个过程。。。我很想听取下朋友们的公司是如何进行这个步骤的，，，和我们一样不需要经过内部review，，还是有一个规范的过程进行内部review。 原帖由 sixsigmay 于 2008-8-25 12:31 发表 http://bbs.51testing.com/images/common/back.gif
嗯是的，我说的场景就是test case，呵呵
嗯是的，我们这边拿到任务时也有这些文档。。。在写场景之前我们接到任务的那个同事都会认真去了解需求和其他文档，，，我部门这边的情况是，写好场景后，同事和开发方、需 ...
我接触过的项目从来没有Review，都是直接自己写了Case就结束了，产品已经拆分为一块一块了，一个人负责一块或几块，这个人就是这块的Owner。
只有每次需要执行Test Pass的时候，或者非Owner添加别人所属模块的Cases才可能需要Owner来review，其他基本没有过，不过我所在的公司只做产品，不做项目，所以没有确切的客户一说，所以可能和你的理解有些差异。 原帖由 lotuis 于 2008-8-25 13:00 发表 http://bbs.51testing.com/images/common/back.gif
我接触过的项目从来没有Review，都是直接自己写了Case就结束了，产品已经拆分为一块一块了，一个人负责一块或几块，这个人就是这块的Owner。
只有每次需要执行Test Pass的时候，或者非Owner添加别人所属模块的Cas ...
嗯，明白了，其实你那边的做法和我这边的差不多，就是一个人负责一个完整的测试，场景自己写，测试自己做等等。。lotuis，这样的模式会不会觉得一个人写的测试不够完整或者觉得有没有别的好的测试分工的。把测试的各个步骤分成一块块来做，生产流水线一样的模式 原帖由 sixsigmay 于 2008-8-25 13:25 发表 http://bbs.51testing.com/images/common/back.gif
嗯，明白了，其实你那边的做法和我这边的差不多，就是一个人负责一个完整的测试，场景自己写，测试自己做等等。。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的牛人要受老板赏识.... 本帖稍后关注。 原帖由 lotuis 于 2008-8-25 15:24 发表 http://bbs.51testing.com/images/common/back.gif
很多公司都是Water Fall的模式，比如微软，不过因为文档相对比较全，所以只要按照文档的范围去写case就可以了，只要覆盖了文档规定的内容，那就是没有问题的。
多嘴一句，case千万别什么都往里面写，虽说要把最 ...
非常感谢指导，嗯继续学习，继续关注 原帖由 lotuis 于 2008-8-25 15:24 发表 http://bbs.51testing.com/images/common/back.gif
很多公司都是Water Fall的模式，比如微软，不过因为文档相对比较全，所以只要按照文档的范围去写case就可以了，只要覆盖了文档规定的内容，那就是没有问题的。
多嘴一句，case千万别什么都往里面写，虽说要把最 ...
呵呵，看来是前辈的经验之谈啦，之前还真没想过这个问题。
我们也是由组长分配各个项目给组员，当然会给很详细的需求文档，然后该组员先写测试计划，写好后由组内进行评审，将遗漏的地方进行补充（我们的测试计划是针对自己内部的，其中包含测试要点）。对于测试用例，到是很少进行很完整的评审，因为太多了，没有那么多的时间、精力。主要由组长在测试的过程中进行一些相关容易遗漏的东西的补充。 1.新人写用例是可以,就当让他们学习写用例的技巧,同时也熟悉了需求,但负责人不一定要采纳他们的.
2.测试组长对版本控制是很重要的,如果不做这项工作的话,会有很多麻烦的.比如说版本发布后,就不能再让开发人员到测试系统上改东西了.我曾经遇到一个很严重的问题,比如说我到V1.0版本上测试发现了一个BUG,由于我没加版本号,他们开发的由于在开发V2.0,就没有回现你在V1.0版本上发现的BUG,这样我的工作就算是白做了.所以后来我就认识到必须要有版本控制的意思.
3.关于版本控制还需要配置和项目经理来共同维护,虽然这样做可能会增加成本,但质量才会有保证. 呵呵，楼主如果是测试部门负责人的话，估计要有好多工作呢。。。
简单就楼主的一些问题做个回答，抛砖引玉下。
[*]首先构建组织结构，确定岗位的职责、义务、权利、汇报人关系等——这些实际上也是人事部门的工作，但是如果人力资源部门没做，那就只好自己做。对自己的部门首先要有个明确的规划，先把坑挖好，再补充人或者技能[*]接下来，就目前的人员组织结构进行调整，把主要的骨干人员集中起来，定制测试的各项流程、规范、确定一般的方法，当然一定要注意随时随地的进行审核确认！这样还没完，初稿完成后需要逐步放到实际情况下验证，看看这些内容是否合适，如果不合适，则修改，直到合适为止。在这里还要注意一个问题，必须把制定的流程、规范等内容列入具体的绩效考核内，这样才可以促进流程、规范的深化[*]鼓励组织内部的导师制，这种制度可以快速把新手变成熟手，不仅要在知识技能上培养，更重要的是让新手参与实践。个人认为经验不是必然的，有经验和没有经验间的差距在于是否不断投入到工作当中，及时把错误纠正过来，不断训练形成经验。[*]注意组织的积累。很多时候员工离职了，经验和知识就大部分消失了，对组织而言，这种损失是无法估量的。不仅仅是看得见的直接成本，也有很多看不到的间接成本，如培训等等。很多人说，我们直接招有经验的不就行了——实际上，这个话题我想人力资源部门会有更好的解释。
讲到具体的测试执行工作，那没什么太多的技巧，扎扎实实才是王道。是否对需求有疏漏，取决于是否有进行具体的分析，是否有可靠的追踪数据，是否能得到有效的确认，而不是个人能力的问题。一个新手接手一个项目的需求，都是从不了解到了解的过程，几乎没什么区别，区别在于工作的方式方法是否正确，之前的准备工作是否妥善完备，之后的检查工作是否到位而已。至于说到如何高效，这里工作的方向和方法可能是决定性的因素，需要摸索工作方法，提升效率，并不断优化这种方法，直到更高效率而已。所以，想问问楼主如何做测试需求分解的，怎样跟踪测试需求变更等这一系列的问题，否则，实难说明。
[*]关于版本控制，不同的公司有不同的做法，有些公司由开发团队管理，有些则由QA组织实施。没有定论。至于说测试部门进行版本控制，那我想可能也就以下几个方面的管理工作[*]控制发布频率[*]控制发布内容/范围[*]管理发布环境具体的发布工作可以请开发团队开发工作或编写脚本完成，QA团队更多地应关心是否已经按流程做了对应的工作，每个步骤是否都检查到了。
希望以上这些可以提供给你帮助。
[ 本帖最后由 archonwang 于 2008-8-27 13:22 编辑 ]
