1. 程式人生 > >廣州軟體測試交流會第六次沙龍案例分析總結【轉載】

廣州軟體測試交流會第六次沙龍案例分析總結【轉載】

A公司軟體外包專案的案例

這是一個ERP軟體外包專案,客戶是某國的一家著名的大企業。

客戶要求的內容很多,也很嚴格,不僅要求使用指定的技術和工具,而且還自主開發了一個平臺,要求在該平臺上進行開發、測試;還有各種文件格式要求和技術要求;最重要的是要保證工期,一定要在4月內提供高質量的、完整的產品。

成立專案組

專案立項後,A公司在開發部、測試部抽調人手成立了專案小組。專案經理是一名在軟體專案方面有多年開發經驗的開發人員,但是,他是第一次帶專案。

專案經理下設三個小組:(每一小組設定一名小組長,配備若干組員)

負責詳細設計的DS小組(6名成員)

負責程式設計的PG小組(5名成員)

負責測試的PT小組(5名成員)

另還有一名使用者參與需求的分析與確認。

專案計劃

專案經理在被指定負責這個專案後,自行制訂了以下專案進度計劃,簡單描述如下:

  1. 5月10日~6月1日需求分析
  2. 6月1日~6月25日系統設計,包括概要設計和詳細設計
    3)6月26日~8月1日編碼
  3. 8月2日~8月31日系統測試
  4. 9月1日試執行

專案進度計劃表

專案各階段

計劃執行時間

參與人員

需求分析和評審

5月10日~6月1日

專案經理、開發人員、使用者代表

系統設計和評審

6月1日~6月25日

專案經理、設計人員

編碼

6月26日~8月1日

開發人員

測試

8月2日~8月31日

測試人員

維護

9月1日試執行

維護人員

專案過程

在專案經理、詳細設計DS小組及使用者的參與下,按原訂的計劃完成了需求的分析工作,順利進入系統設計的階段,在6月15日專案經理檢查工作時發現,按此時的工作進度不可能如期完成系統設計的工作,但使用者所要求的工期是不可能推遲的,專案經理在沒有與測試組長討論的情況下就決定縮短系統測試的時間,在系統設計階段推遲了10天(7月5日)才進入了編碼階段,為了保證工期,專案經理決定二個小組同時進行,並行工作。編碼人員投入編碼,而測試組成員同時編制測試設計書,並設計測試資料。

由於系統設計做得比較好,而程式設計人員的水平也比較穩定,程式設計人員按原計劃所需要的時間內完成了任務,於8月11日把第一版的程式提交測試人員及使用者代表,此時離交貨期只有20天的時間,為了趕進度,測試PT小組的組長最後只能通過加班加點和增加2名測試人員的安排來開展工作。

使用者代表看了開發出來的測試版本後,提出需求變更要求,專案經理覺得需求變更對軟體修改不大,沒有與相關人員討論,就直接讓程式設計人員修改,並重新打包提交測試。

在測試的過程中,測試發現比較多的問題,其中關於使用者易操作性方面的問題,與開發的意見相持不下,測試人員認為這些問題比較重要的且必需改,而開發人員則認為問題不大,用用就習慣了,最後,問題反饋到了專案經理處,專案經理為了能保證工期,贊同開發人員的意見,不需要修改。

由於測試的時間與工作量一開始就沒有得到詳細的評估,且測試人員對業務需求瞭解不深,測試過程並不順利,從而導致測試時間沒有得到很好的保證,不過經過大家的齊心協力,加班加點,在預定截止日期的當天,所有程式都開發完畢,測試完畢,只是還有很多問題和錯誤需要修正。

為了保證工期,專案經理決定暫時將把有問題的功能及問題隱蔽,將所有的測試報告中的“再確認”一欄填寫上“OK”。專案經理提交所有預定提交的成果。同時,PG和PT人員仍在繼續奮戰。

一週後,使用者發過來大量問題,絕大部分是易操作性的問題,還有小部分是功能沒有達到要求。專案小組繼續修正問題,一個月後,使用者同意驗收,專案終於結束了,專案小組才得以解散。

專案最終執行表

專案各階段

計劃執行時間

參與人員

實際完成時間

實際完成情況

需求分析和評審

5月10日~6月1日

專案經理

開發人員

使用者代表

6月1日

按計劃完成,順利進入系統設計的階段

系統設計和評審

6月1日~6月25日

專案經理

設計人員

7月5日

在系統設計階段推遲了10天才進入編碼階段

編碼

6月26日~8月1日

開發人員

8月11日

按原計劃所需時間完成,但受設計階段影響,完成時間順延10天

測試

8月2日~8月31日

測試人員

8月31日

通過加班和增加人手來完成測試工作,但發現的部分問題沒得到解決

維護

9月1日試執行

維護人員

9月30日

提交後用戶不斷反饋問題,問題解決後用戶驗收

案例分析

1、 A公司的軟體外包專案得到了使用者的驗收,請問此專案是成功還是失敗?為什麼?

2、 在我們的實際工作當中,經常會出現由於測試過程中發現問題,程式需要修改,導致專案或產品需要延遲釋出,也經常會出現專案或產品釋出後還會有問題,對於這些問題,請問您認為這是測試人員的責任嗎?

3、本案例中在成本、進度、風險和質量方面主要存在著哪些問題?與測試人員密切相關的問題有哪些?

4、我們有沒有辦法去避免這些問題的發生?

第六次交流會 第二主題的論點歸納

1、 專案已提交驗收,但專案有延期且出現問題,問:此項止是否算成功?
1) 觀點一:結合專案背景,站在商業利益的角度,此專案成功,因為專案已得到使用者的驗收,也就是說公司是能夠收到專案款項,這個專案應該算成功的。
2) 觀點二:站在質量和管理的角度,此專案失敗,專案沒有得到很好的計劃與控制,專案也沒有從使用者的角度考慮問題,質量方面沒有得到控制。後果是增加後期維護工作量,同時必將對公司的聲譽造成不良影響。

2、 專案的延遲和釋出後產生的質量問題,是不是測試人員的責任?如果不是,應該是誰的責任?
1) 專案的延遲和釋出後產生的質量問題,完全不是測試人員的責任,這應該與專案經理有關係,是專案經理在整個專案的控制中沒有做好。
2) 專案的延遲和釋出後產生的質量問題,完全不是測試人員的責任,但應該是測試經理的責任,測試經理沒有與專案經理協調好,沒有主動安排測試人員儘早介入,造成測試人員非常被動。
3) 專案的延遲和釋出後產生的質量問題,測試人員需要承擔一點責任,主要是沒有主動地瞭解專案的需求和進度,一直處於被動的角色,作為整個專案的一員,應該共同去承擔這種責任。

3、 在本個案例中,主要存在哪些問題?
1) 測試人員沒有在需求階段介入,導致測試對需求理解不夠;
2) 專案經理的管理經驗比較缺乏,沒有對專案作好評估,沒有客觀地做好專案計劃和控制專案進度,即沒有一個合格的專案經理;
3) 測試經理的主動管理意識欠缺,沒有及時與專案經理了解其他小組的進度情況;
4) 專案的變更控制和風險計劃沒有做,需求出現變更時,沒有得到有效的評估就草率修改;
5) 專案的管理流程不規範,沒有根據實際情況及時調整開發模式,不應採用瀑布式開發。
6) 整個專案中缺乏了QA的角色,當出現對BUG有分岐時,沒有客觀的內部組織協調好;
7) 客戶代表沒有發揮好作用,在專案過程中沒有過多的參與。
8) 沒有賦予測試組相應的權利,對軟體質量進行客觀準確評測,專案質量和進度完全依靠專案經理一個人掌控,增加了專案失敗的風險。

4、 測試人員是質量體系中,應該屬於質量保證的角色還是保證質量的角色?兩者有什麼不一樣?
測試人員永遠不可能保證質量,測試人員只能做事後的質量保證,保證質量是整個企業的質量管理體系相關,與企業的軟體過程成熟度相關。
測試屬於質量控制(QC),關注結果的度量和BUG 的糾正;
相比之下,質量保證(QA)關注軟體開發流程的制定和執行。
QA和QC都是質量管理體系中不可缺少的一環。質保流程需要根據測試結果不斷改進,同時測試結果驗證質保流程的有效性。