很早了，那个时候我应该刚去软件工程不久。
ericzhangali（另一个空间）
用三个角色来描述：开发部门，测试部门，客户。
公司和客户合作的方式是根据客户一个模糊的需求做出原型，由客户使用后一次次提出修改意见，一次次修改后由客户决定何时可以量产。
目前的流程是：
1）开发人员有新版本直接release给客户，以改动大小和多少决定是否送测试部门测试。
2）客户收到版本后评测，把修改意见反馈给开发人员。
3）测试部门收到测试需求后测试，并把测试结果反馈给开发人员。
出现的问题是：
1）如果开发人员决定需要送测，往往也是在送测的同时已经release给客户。测试是否失去了部分意义。
2）开发人员只关注客户反馈的需求和bug，并不关心测试部门反馈的bug。测试是否失去了部分意义。
3）测试人员不了解客户需求，测试工作无法把握重点。
4）如果流程管理认为测试部门应该把握release产品的质量，要求每次release前都要送测，是否合理。（背景是经常客户要求很急，上午的电话或mail，下午就要新版本。）
希望讨论的问题除了上面的之外还有，
1）项目经理/产品经理如何协调这三者的关系？
2）与客户打交道的窗口是在开发部门合适还是在质量部门（测试部门）合适？
（虽然与测试紧密相关，但揣测一下，觉得还是发在项目管理区。）
1 楼AlexLJM（遁去的一）
1）如果开发人员决定需要送测，往往也是在送测的同时已经release给客户。测试是否失去了部分意义。
-----------------------------------------------------------------------------
這種是Alpha和Beta測試同時進行.其實關注點不同,不能就說就沒意義.
2）开发人员只关注客户反馈的需求和bug，并不关心测试部门反馈的bug。测试是否失去了部分意义。
-----------------------------------------------------------------------------
如果開發不關心測試的意見,那按照我們這裡的話來說就是瞎忙活.測試最終的目的是為了更好的為產品質量服務.其實我們有時候的角色也有點Client.把1)和2)和起來看.這產品就根本不需要測試跟進.
3）测试人员不了解客户需求，测试工作无法把握重点。
---------------------------------------------------------------------------
沒有需求的測試是盲目的.盲目的測試有時候不僅提高不了產品質量還會給整個產品帶來副作用.不過很多公司都沒有書面需求的習慣.這個時候就要測試人員具有需求分析的能力甚至要親自收集客戶的意見.
4）如果流程管理认为测试部门应该把握release产品的质量，要求每次release前都要送测，是否合理。（背景是经常客户要求很急，上午的电话或mail，下午就要新版本。）
--------------------------------------------------------------------------
按照我公司的流程.這個版本是不可能出去的,除非研發自己承擔後果.(我公司產品release一般需要QA部門的簽字)
1）项目经理/产品经理如何协调这三者的关系？
-----------------------------------------
項目經理更多的是要對產品負責,產品經理則要對客戶負責.項目經理負責研發/測試的梳理和協調工作.產品經理負責客戶的說服/說明以及協調工作.這裡面其實就是項目經理和產品經理之間溝通問題.
2）与客户打交道的窗口是在开发部门合适还是在质量部门（测试部门）合适？
----------------------------------------------------------------
不知道其他公司怎麼處理.我公司基本上研發/測試都有與客戶打交道的機會.測試部門甚至以後會成半個客服部門.我覺得無論研發還是測試,都應該多了解市場,多了解客戶的想法.具體到打交道,一個項目的研發/測試主要負責人一起出發.呵呵.
頭有點大.隨便說了點自己的感想.樓下的朋友繼續。
2 楼pyp（鹿鸣）
按照标准的开发流程，任何不经过测试的产品，都不能发给客户。
没有测试部门的确认，软件产品的质量问题由项目组负责，测试部门不承担任何的责任。
如果开发部门不支持测试部门的工作，测试部门有权利不测试产品。
“测试人员不了解客户需求，测试工作无法把握重点。”这个问题问的很好，每一个测试人员对此都会迷茫，主要是时间和经验的关系，小软件好把握，但大的系统，如果没有经过系统的培训是很难了解软件过程的。所以真正测试行业软件的时候，都需要有相关行业经验的参加测试小组或做为顾问。测试小组也需要进行一定 的培训。（我测试过很多比较大的家伙，了解那些东西就要花费很长的时间，实际很多的项目，测试3、4次才知道里面的东西具体是怎么运作的）。
上面是测试部门的一些事情。下面说说管理方面的。
在实际过程中，测试部门一般都比较的弱势，除非公司特别重视产品的质量。很多的时候，留给测试的时间都不够，在软件行业的都知道，项目很少有按时完成的， 基本都会拖期，这个时候影响最大的其实就是测试。如果客户急着要，即使产品没有经过严格的检验一般也都发出去了。
项目经理的责任就是严格的掌握开发时间，了解客户的需求，和测试部门进行协调，准备好一切测试部门的相关资料。（现在程序员都在赶进度，基本没有文档，所以在测试前写测试用例是基本不可能的，反正至少在我工作过的公司，无论是程序员的设计还是测试人员的用例等，都是事后补的，这是没有办法的事情）。
在很多的时候，测试部门可以说是代表客户利益的，但真正成熟的软件公司，分工都很详细，比如有专门的需求设计人员，负责和客户打交道；还有专门的售后服务技术支持人员；通常测试部门只负责产品的质量，不会和客户发生关系。
3 楼AlexLJM（遁去的一）
在很多的时候，测试部门可以说是代表客户利益的，但真正成熟的软件公司，分工都很详细，比如有专门的需求设计人员，负责和客户打交道；还有专门的售后服务技术支持人员；通常测试部门只负责产品的质量，不会和客户发生关系。
----------------------------------------------------
我們公司以前就是這樣做的.可惜在定位一些問題要不要改善的時候,經常要經過一個流程才能反饋回結果,有時候這個結果根本就不符合我們的需要.後來痛定思痛,決定減少這個流程.
4 楼pyp（鹿鸣）
测试部门测试完毕签字确认后，实际就已经和项目没有什么关系了。除非有太大的质量问题出现，表明是测试部门的责任，这个时候会由公司给予测试部门相应的处罚，与客户或项目组无关。
至于客户的问题，应该有技术支持人员（通常由开发人员兼职或转职）解决。
技术支持人员解决不了的问题，如果原项目组还存在，反馈给项目组；项目组解决不了的，就告诉客户下一版本解决，能拖则拖，拖到客户忘了为止。
如果项目组不存在，而问题真的很多，客户还必须使用这个软件。那真是太好了，赶紧重新组织项目组，开发2.0，又能挣一笔钱，哈哈。
5 楼AlexLJM（遁去的一）
技术支持人员解决不了的问题，如果原项目组还存在，反馈给项目组；项目组解决不了的，就告诉客户下一版本解决，能拖则拖，拖到客户忘了为止。
如果项目组不存在，而问题真的很多，客户还必须使用这个软件。那真是太好了，赶紧重新组织项目组，开发2.0，又能挣一笔钱，哈哈。
---------------------------------------
好方法.....
6 楼ericzhangali（另一个空间）
同意楼上两位说的流程。但是感觉目前的情况是把测试工作划分一部分到客户的相关部门。客户认同的方式似乎就是发版本给他，他测试，提交bug list和修改意见，修改后再发给他，他再测试...直到他满意，这里面的一次次release我个人觉得不是很正式。在时间压力大的时候或改动很微小的 时候，这种不是很正式的release是不是一定要送测，在VSS上打label，然后得到一份不是很关注的测试报告呢？因为同时版本也已发给了客户，也 许很快，客户也反馈了报告。
往往有一个现象就是客户提交的bug list和测试部门提交的差别很大。倒不认为这是alpha和beta同时进行。
这种方式确实测试部门不承担责任。由开发部门/人员承担。
至于测试人员了解需求的问题，情况是，对每个客户，产品的功能大致是相同的，测试人员也是比较了解的，也有老手写好的full test用例和simple test用例。但每个具体的客户可能外观要求不同，有的功能细节有不一致，甚至不同客户关注的问题点也不同。我是指这个情况测试人员不了解，这个情况只有 直接和客户联系的开发人员了解。但开发人员又没有太多时间跟测试人员详细说。
如果把窗口转移到测试部门，不知道客户会不会有意见。他们可能更希望和直接的开发人员联系，提出需求。
7 楼ericzhangali（另一个空间）
两位可能不太了解我的情况，我口才有限，觉得有些表达不清楚。呵呵。
我觉得可以理解成原型法的一个挖掘需求阶段，但又不完全是挖掘需求。
大致的过程是：
当接到一个新的客户时，我们按照他们要求的功能和UI大致做一个实现，砍到我们认为我们的solution暂时做不到的，或行为和我们的solution差别比较大的就劝说按我们的方式做。
得到这个实现后，客户就不断地测试，递交bug list和需要修改的需求。
我们就不断地给他新版本。
这个过程可能超过一个月，频率可能一两天或两三天就发出一个新版。
同时我们自己的测试部门也做测试，发现的问题，优先处理严重的。
直到客户觉得基本达到其要求，他才会量产、小批的给他的客户试用。
然后反馈试用出的问题和需求，我们再做修改。这个频率一般不高。
再然后，他才正式量产。
我觉得，小批生产前的是不是属于正式的发布？是否一样地需要严格按流程管理？
8 楼AlexLJM（遁去的一）
我觉得，小批生产前的是不是属于正式的发布？是否一样地需要严格按流程管理？
-------------------------------------------------------------------
當然不算正式發布,頂多算個驗收測試.看你說的情況,嚴格按照流程管理只會增加管理成本,導致項目延期.
9 楼pyp（鹿鸣）
现在规模软件开发，重视的是开发流程，努力找到一种适普和容易控制的开发方法。
但理论和实践是有差别的，所以才有一个不断调整的过程。
这样，根据不同的实际情况，可以对软件开发流程有自己的理解和方法。
现在流行的剪裁rup就是为了适应各种不同的情况而实施的。
所以很难说哪个好或不好。
但通常情况下，流行的方法都是经过理论和大量实践，所以一般都适合于各种情况。
至于你们公司，是否有修改的可能和必要？如果没有，那么当前这种开发情况就是最合适的。
否则可以找咨询公司，为你们公司的实际情况设计一套开发方案，这涉及大量的细节，这里简略的讨论实在不是很合适。
10 楼ericzhangali（另一个空间）
呵呵。质量流程部门坚持要每次release前都送测，他们好象不在乎送测的意义有多少。
11 楼ericzhangali（另一个空间）
看你說的情況,嚴格按照流程管理只會增加管理成本,導致項目延期.
-------------------------------------------------------------
说服不了测试部门。
12 楼ericzhangali（另一个空间）
我觉得对release的定义模糊。
客户工程师一个电话打来说改一个bug，马上发个新版，是不是一次release。
如果只要有送出就要经过测试的话，我觉得还是由测试部门和客户打交道吧，接收需求，研发修改，提交测试，再送出。至于时间，由测试部门去和客户协调。
13 楼wbsndts（磨牙小胖鼠）
按照这样的现实情况，谈需求的窗口不应该是研发部门了。
14 楼ericzhangali（另一个空间）
唉，规则都是人制定的，也都是人执行的，混吧。
由于测试的人远离客户，他们不清楚客户的需求的关注的权重，往往他们报来的bug和客户提出的bug相差很远。
我们只能优先考虑客户的bug，而渐渐疏远公司流程中测试活动的产物。
这日子只能先这样过了...
扫一扫
120
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
