産品部：負責需求采集，需求說明說編寫，後期的需求變更。
研發部：負責需求的具體實作，測試階段負責對測試的支援和缺陷的修改。
測試部：負責産品上線前的測試工作。
每個部門在整個軟體過程都肩負着不通的責任分工，但每個部門之間又形成了一個互相依存，互相促進的關系。就拿需求來說吧，需求真是反映了客戶的需要，需求又是研發部技術實作的唯一标準，要求100%按照需求來實作代碼，并且不多也不少；需求是測試人員設計測試用例時唯一正确的預期結果，一切與需求不符的都視為缺陷。相反，研發人員和測試人員作為産品的第一使用者，又對需求起着診斷的作用，不斷的發現不合理的需求或者是新增需求，并提出需求變更。
同時，産品部還有跟蹤測試進度，監督測試品質的職責，那麼這些都怎麼來保證有效的實施？ 有什麼樣的标準去衡量品質？怎樣跟蹤進度？怎樣來對需求做出科學合理的管理呢？
CMMI，大家所熟悉的名字，正是一些大公司在解決這些具體問題時所總結的經驗，并形成了具體的管理過程，制定了有效的流程和标準，然後才得到世界的認可并成為一種标準。
說這些的目的是，公司應該根據自己具體的情況來實施品質管理的整個過程，誰又能說我們的這套标準若幹年後不能成為電信增值行業的标準呢？畢竟品質管理方面現在大家都處在探索階段。我想這正是中國大部分軟體企業所缺少的，不注重對理論知識的探索和知識産權的追求。（說的有點大，哈）
簡而言之，目前我們所說的狹義的品質管理是刨去市場營運，單純的就整個開發過程（指的是産品上線前的階段，這裡并沒有忽視産品維護，而是分而談之）而言，工作所圍繞的中心是項目的整體進度和品質，也就是說怎麼樣在最短的時間内，把高品質的産品開發出來，然後投入市場。這樣就存在兩個沖突，一個是時間上的，想把産品盡早的投入市場而縮短開發的周期；另一個沖突是不斷的擔心品質問題的出現，因為産品上線後發現問題，去解決所需要花費的成本是成倍的增加。
我一直在思考，品質管理的過程可不可以以成本為導向？使各部門都以此為目标去參加品質管理。其實無論以品質為導向，還是以成本為導向，我們的最終目标都是一樣的-----縮短開發周期，提高軟體品質。就像教育孩子，爸爸告訴兒子說，期末考試不及格我打你屁股，而媽媽告訴兒子說，期末考試都幾個了，我帶你去公園玩。那個方法更有效呢，答案不言而明了。以成本為導向的軟體管理，正是這種讓管理者去主動的思考如何利用品質管理降低成本，而不是單純的去承受品質管理所帶來的壓力。
下面我簡單的就如何在保證軟體品質的過程中，各部門所應該起到的作用說一下個人觀點。
産品部：負責需求采集，需求說明說編寫，後期的需求變更。另外還負責對整個項目進度的跟蹤，及品質的監督。
可以說，産品部在整個軟體過程起着非常重要的作用。首先，産品部是最了解客戶需求的人員，也是主動去采集客戶需求的人員。如果産品部對客戶的需求非常明确，就能寫出非常詳細且需求明确的需求說明書，一份這樣的說明書，将對研發部和測試部有着極大的幫助。
據統計，有80%的缺陷直接來自需求，包括采集需求階段對需求不了解，了解不全面，或者主觀的判斷錯客戶的需求；包括由于需求說明書不詳細，不明确，導緻開發人員對需求的了解有偏差或者錯誤，開發出不适合客戶需要的功能；包括測試人員無法從需求說明書中獲得正确的測試需求，以至于失去衡量功能點是否正确的标準。
其次，客戶的需求并不需要客戶直接提出來，而有很多的隐含需求是需要我們産品人員去主動發掘的。比如網站産品的個人管理界面，客戶沒有提出美觀大方的要求，但我們也要給他們這種美感，并且給予充分的提示資訊，讓客戶輕松友善的進行配置管理；再比如，客戶沒有提出對通話清晰度的要求，但我們要在滿足客戶通話最低品質标準上，不斷的提高通話品質，這些就是客戶沒有提出，但我們應該知道這正是客戶需要的隐含需求。
第三，産品部還負責線上問題的采集。包括線上發現的缺陷，客戶提出的新需求等。線上缺陷可以歸位到我們的缺陷庫，防止以後測試時遺漏。客戶新需要為我們産品的更新提供參考價值。這些都需要慢慢的積累，是一筆寶貴的财富。
具體實施的建議：
● 制定符合公司的需求采集流程。公司個人産品，公司企業産品還有國際産品，使用者群體的不通而擷取需求的管道就不通。
● 制動标準的需求說明書模闆。
● 産品部對需求說明書初稿的評審，确認需求正确，明确。（保證需求說明書中的需求是客戶真是的需要）
● 需求說明書移交研發部和測試部，并主動幫助研發人員和測試人員正确的了解需求。（保證向研發人員和測試人員準确轉達了客戶的需要）
● 對項目進度的跟蹤，對項目品質的控制。
● 對需求變更的管理
建議适當的時候啟用需求管理工具，對需求的管理，對需求變更的管理将十分的清晰。
研發部：前期負責具體需求的技術實作，測試階段負責對測試人員的支援，缺陷的修改。
簡單的說，隻要對需求了解充分，代碼實作就容易很多。 我隻說些對品質管理和對測試部門比較重要的部分。
1. 規範的開發流程，生成概要設計文檔，詳細設計文檔及其他技術性文檔，還包括産品安裝解除安裝手冊，配置手冊，使用者使用手冊等。其中面向客戶的文檔也是需要經過測試部門測試的。
2. 開發階段的測試工作。由開發人員執行單元測試，內建測試等，保證移交到測試部門的産品符合測試啟動标準（測試啟動标準由測試部門制定）
3. 嚴格的需求管理與版本管理。如果開發人員覺得某個需求應該改動，必須與産品部溝通，嚴格走需求變更流程，不允許私自更改需求。 版本管理，沒有經過測試的産品不私自線上部署。
建議有一名專門的配置管理，版本管理人員。
測試部門：執行産品上線前的測試工作，保證産品達到上線标準方可通過測試。
一個優秀的測試團隊至少應該包括以下三個方面：
1. 合理的測試技能搭配。
一個測試團隊并不都需要經驗豐富，技術過硬的“全才”，有一個梯度是最好的選擇。
畢竟讓一個經驗豐富的高幾工程師去測試簡單的功能測試，時間久了他就會失去興趣。而讓他寫一些測試方案，把經驗傳授給初級測試工程師，卻迎合了他的技術特點，這對測試新人也是一種成長。
還有功能測試，性能測試，自動化測試等，都需要合理的技能搭配。
2. 建立合理的測試流程，測試标準。
包括：
●啟動測試标準： 定義了可以接收測試項目的标準
研發部把産品送出測試部之前，需要組織人員測試，保證基本功能，基本業務流程沒有錯誤，保證實作了需求說明書中的全部内容。這樣可以避免把帶有嚴重的卻容易發現的缺陷的産品送出給測試，而啟動了測試資源，生成了測試成本後，卻無法執行下去。
●中止測試标準： 定義了可以中途停止測試的标準
在測試進行過程中，當發現有嚴重缺陷而導緻基本功能，基本流程無法執行時，應中止測試，傳回研發人員。
●通過測試标準： 定義了通過測試，可以上線的标準
當所有high以上的缺陷均被修複，而其他缺陷均不影響産品的功能，使用時，可視為測試通過。
●設計用例标準：定義了以個規範的編寫用例标準和屬性
規範了用例的外在屬性：測試目的，測試環境，測試資料，測試前提，備注等。
規範了用例的内在屬性：用例标題，用例步驟，用例期望，用例執行結果。
●缺陷生命周期：定義了一個缺陷被處理的整個過程
QC管理工具為缺陷提供了一個在測試和開發人員之間的交流平台，交流的過程以改變缺陷的狀态為标示，并要求雙方寫明處理的理由。便于缺陷的跟蹤和修複确認。
●缺陷級别劃分： 定義了缺陷的等級，及等級的劃分标準
根據缺陷對系統的影響程度，賦予了不通的等級，等級高的會被優先處理。等級高的缺陷越多，說明系統的品質越差。
●測試計劃模闆：
測試計劃一般包括：測試的時間安排，測試資源的劃分，測試風險的應對等主要内容。
●測試方案模闆：
測試方案寫明本次測試應該被怎麼執行，怎麼來測試才能效果更好，它寫明測試的内容，測試的方法，測試的重點和一些注意事項，供測試人員在實際測試過程中參考。
●階段測試報告模闆：
測試人員對自己負責測試的項目,内容進行總結，是對自己工作的一個回顧總結的過程。
●總結性測試報告模闆：
一般由項目的主要測試負責人負責編寫，分析整個項目的測試過程，測試覆寫，用例執行情況，缺陷修複情況，提一些建議或者新需求等，供與項目有關的所有人員清楚的看到測試的整個過程，清楚的認識項目的品質，進而評判産品能否上線。
3. 測試團隊組織建設與教育訓練
組織建設包括一些集體活動
教育訓練包括測試素質教育訓練，測試技能教育訓練。
還可以進行每周一問一答活動，由所有測試人員共同思考測試有關的某一問題，集衆人智慧，建設公司自己的測試知識體系。
這些都是有利于測試團隊的成長，融洽的團隊氛圍，積極的團隊精神面貌，提高測試水準，增加忠誠度等。
總結：測試的品質管理隻要抓住從整體角度入手，發揮各部門協調處理問題的能力，對整個過程制定一系列流程和約定，對整個實施過程都要有文字記錄，對每一個結果都要進行總結和存檔。一句話，使整個品質管理過程變成一個可看得見的，可控制的，能夠預測規避風險的過程，這也是CMMI的精髓所在。