送測和釋出關系的讨論

問題描述：

　　ericzhangali：

　　公司和客戶合作的方式是根據客戶一個模糊的需求做出原型，由客戶使用後一次次提出修改意見，一次次修改後由客戶決定何時可以量産。

　　目前的流程是：

　　1）開發人員有新版本直接release給客戶，以改動大小和多少決定是否送測試部門測試。

　　2）客戶收到版本後評測，把修改意見回報給開發人員。

　　3）測試部門收到測試需求後測試，并把測試結果回報給開發人員。

　　出現的問題是：

　　1）如果開發人員決定需要送測，往往也是在送測的同時已經release給客戶。測試是否失去了部分意義。

　　2）開發人員隻關注客戶回報的需求和bug，并不關心測試部門回報的bug。測試是否失去了部分意義。

　　4）如果流程管理認為測試部門應該把握release産品的品質，要求每次release前都要送測，是否合理。（背景是經常客戶要求很急，上午的電話或mail，下午就要新版本。）

　　希望讨論的問題除了上面的之外還有，

　　1）項目經理/産品經理如何協調這三者的關系？

　　2）與客戶打交道的視窗是在開發部門合适還是在品質部門（測試部門）合适？

　　精彩回複：

　　alexljm：

　　這種是alpha和beta測試同時進行。其實關注點不同，不能就說就沒意義。

　　如果開發不關心測試的意見，那按照我們這裡的話來說就是瞎忙活。測試最終的目的是為了更好的為産品品質服務。其實我們有時候的角色也有點client。把1）和2）和起來看。這産品就根本不需要測試跟進。

　　3）測試人員不了解客戶需求，測試工作無法把握重點。

　　沒有需求的測試是盲目的。盲目的測試有時候不僅提高不了産品品質還會給整個産品帶來副作用。不過很多公司都沒有書面需求的習慣。這個時候就要測試人員具有需求分析的能力甚至要親自收集客戶的意見。

　　按照我公司的流程。這個版本是不可能出去的，除非研發自己承擔後果。（我公司産品release一般需要qa部門的簽字）

　　項目經理更多的是要對産品負責，産品經理則要對客戶負責。項目經理負責研發/測試的梳理和協調工作。産品經理負責客戶的說服/說明以及協調工作。這裡面其實就是項目經理和産品經理之間溝通問題。

　　不知道其他公司怎麼處理。我公司基本上研發/測試都有與客戶打交道的機會。測試部門甚至以後會成半個客服部門。我覺得無論研發還是測試，都應該多了解市場，多了解客戶的想法。具體到打交道，一個項目的研發/測試主要負責人一起出發。呵呵。

鹿鳴：

　　按照标準的開發流程，任何不經過測試的産品，都不能發給客戶。

　　沒有測試部門的确認，軟體産品的品質問題由項目組負責，測試部門不承擔任何的責任。

　　如果開發部門不支援測試部門的工作，測試部門有權利不測試産品。

　　“測試人員不了解客戶需求，測試工作無法把握重點。”這個問題問的很好，每一個測試人員對此都會迷茫，主要是時間和經驗的關系，小軟體好把握，但大的系統，如果沒有經過系統的教育訓練是很難了解軟體過程的。是以真正測試行業軟體的時候，都需要有相關行業經驗的參加測試小組或做為顧問。測試小組也需要進行一定 的教育訓練。（我測試過很多比較大的家夥，了解那些東西就要花費很長的時間，實際很多的項目，測試3、4次才知道裡面的東西具體是怎麼運作的）。

　　上面是測試部門的一些事情。下面說說管理方面的。

　　在實際過程中，測試部門一般都比較的弱勢，除非公司特别重視産品的品質。很多的時候，留給測試的時間都不夠，在軟體行業的都知道，項目很少有按時完成的， 基本都會拖期，這個時候影響最大的其實就是測試。如果客戶急着要，即使産品沒有經過嚴格的檢驗一般也都發出去了。

　　項目經理的責任就是嚴格的掌握開發時間，了解客戶的需求，和測試部門進行協調，準備好一切測試部門的相關資料。（現在程式員都在趕進度，基本沒有文檔，是以在測試前寫測試用例是基本不可能的，反正至少在我工作過的公司，無論是程式員的設計還是測試人員的用例等，都是事後補的，這是沒有辦法的事情）。

　　在很多的時候，測試部門可以說是代表客戶利益的，但真正成熟的軟體公司，分工都很詳細，比如有專門的需求設計人員，負責和客戶打交道；還有專門的售後服務技術支援人員；通常測試部門隻負責産品的品質，不會和客戶發生關系。

　　我們公司以前就是這樣做的。可惜在定位一些問題要不要改善的時候，經常要經過一個流程才能回報回結果，有時候這個結果根本就不符合我們的需要。後來痛定思痛，決定減少這個流程。

　　鹿鳴：

　　測試部門測試完畢簽字确認後，實際就已經和項目沒有什麼關系了。除非有太大的品質問題出現，表明是測試部門的責任，這個時候會由公司給予測試部門相應的處罰，與客戶或項目組無關。

　　至于客戶的問題，應該有技術支援人員（通常由開發人員兼職或轉職）解決。

　　技術支援人員解決不了的問題，如果原項目組還存在，回報給項目組；項目組解決不了的，就告訴客戶下一版本解決，能拖則拖，拖到客戶忘了為止。

　　如果項目組不存在，而問題真的很多，客戶還必須使用這個軟體。那真是太好了，趕緊重新組織項目組，開發2.0，又能掙一筆錢，哈哈。

　　同意樓上兩位說的流程。但是感覺目前的情況是把測試工作劃分一部分到客戶的相關部門。客戶認同的方式似乎就是發版本給他，他測試，送出bug list和修改意見，修改後再發給他，他再測試。。。直到他滿意，這裡面的一次次release我個人覺得不是很正式。在時間壓力大的時候或改動很微小的 時候，這種不是很正式的release是不是一定要送測，在vss上打label，然後得到一份不是很關注的測試報告呢？因為同時版本也已發給了客戶，也 許很快，客戶也回報了報告。

　　往往有一個現象就是客戶送出的bug list和測試部門送出的差别很大。倒不認為這是alpha和beta同時進行。

　　這種方式确實測試部門不承擔責任。由開發部門/人員承擔。

　　至于測試人員了解需求的問題，情況是，對每個客戶，産品的功能大緻是相同的，測試人員也是比較了解的，也有老手寫好的full test用例和simple test用例。但每個具體的客戶可能外觀要求不同，有的功能細節有不一緻，甚至不同客戶關注的問題點也不同。我是指這個情況測試人員不了解，這個情況隻有 直接和客戶聯系的開發人員了解。但開發人員又沒有太多時間跟測試人員詳細說。

　　如果把視窗轉移到測試部門，不知道客戶會不會有意見。他們可能更希望和直接的開發人員聯系，提出需求。

ericzhangali：

　　兩位可能不太了解我的情況，我口才有限，覺得有些表達不清楚。呵呵。

　　我覺得可以了解成原型法的一個挖掘需求階段，但又不完全是挖掘需求。

　　大緻的過程是：

　　當接到一個新的客戶時，我們按照他們要求的功能和ui大緻做一個實作，砍到我們認為我們的solution暫時做不到的，或行為和我們的solution差别比較大的就勸說按我們的方式做。得到這個實作後，客戶就不斷地測試，遞交bug list和需要修改的需求，我們就不斷地給他新版本。

　　這個過程可能超過一個月，頻率可能一兩天或兩三天就發出一個新版。同時我們自己的測試部門也做測試，發現的問題，優先處理嚴重的。直到客戶覺得基本達到其要求，他才會量産、小批的給他的客戶試用。然後回報試用出的問題和需求，我們再做修改。這個頻率一般不高。再然後，他才正式量産。

　　我覺得，小批生産前的是不是屬于正式的釋出？是否一樣地需要嚴格按流程管理？

　　當然不算正式釋出，頂多算個驗收測試。看你說的情況，嚴格按照流程管理隻會增加管理成本，導緻項目延期。

　　現在規模軟體開發，重視的是開發流程，努力找到一種适普和容易控制的開發方法。但理論和實踐是有差别的，是以才有一個不斷調整的過程。這樣，根據不同的實際情況，可以對軟體開發流程有自己的了解和方法。

　　現在流行的剪裁rup就是為了适應各種不同的情況而實施的。是以很難說哪個好或不好。但通常情況下，流行的方法都是經過理論和大量實踐，是以一般都适合于各種情況。

　　至于你們公司，是否有修改的可能和必要？如果沒有，那麼目前這種開發情況就是最合适的。否則可以找咨詢公司，為你們公司的實際情況設計一套開發方案，這涉及大量的細節，這裡簡略的讨論實在不是很合适。

　　呵呵。品質流程部門堅持要每次release前都送測，他們好象不在乎送測的意義有多少。看你說的情況，嚴格按照流程管理隻會增加管理成本，導緻項目延期，說服不了測試部門。

　　我覺得對release的定義模糊。

　　客戶工程師一個電話打來說改一個bug，馬上發個新版，是不是一次release。

　　如果隻要有送出就要經過測試的話，我覺得還是由測試部門和客戶打交道吧，接收需求，研發修改，送出測試，再送出。至于時間，由測試部門去和客戶協調。

　　wbsndts：

　　按照這樣的現實情況，談需求的視窗不應該是研發部門了。

　　唉，規則都是人制定的，也都是人執行的，混吧。

　　由于測試的人遠離客戶，他們不清楚客戶的需求的關注的權重，往往他們報來的bug和客戶提出的bug相差很遠。我們隻能優先考慮客戶的bug，而漸漸疏遠公司流程中測試活動的産物。

　　這日子隻能先這樣過了。。。

====================================分割線================================

最新内容請見作者的github頁：http://qaseven.github.io/