過程階段評審，無評審，不過關！
還記得在我們還是學生的年代，每次考試交卷前都會檢查好幾遍，生怕錯漏了什麼，實際上就是開展了一次評審活動，評審的人是你，評審的物件是那份卷子，評審的目的是為了發現問題並修改。
在軟體生產過程中，涉及到一道道環節，軟體生命週期從專案啟動到需求，緊跟著設計，然後開發，之後測試，測完了上線，最後一段日子的運維，為了保證順利進入下乙個環節，通常會要求在上個環節的出口前（下個環節的入口前），開展階段評審，評審不過關的，要麼修復問題，要麼評估影響後才能進入下一階段。
恐怕很多人都不知道，團隊在進入軟體生產前還需要做乙個評審，那就是團隊成熟度評審，這個評審的目的是為了檢查團隊是否有足夠的能力勝任接下來的專案工程，通常會從人員的技能、經驗、領導者（pm、pl等）的管理能力、團隊軟硬體資源、人力的準備程度，這些方面去評估，在這篇文章中我們著重講評審的大體活動，就不額外展開了。
那麼評審的目的是什麼呢？流程大概有哪些內容？
眾所周知，越早發現問題，修復改正的成本越低，評審的目的正是為了早期發現問題以提高質量，所以評審會在軟體生產過程中設立乙個個評審點，這乙個個檢查點銜接了每乙個環節，保證了生產質量。
至於評審的流程，簡單說來有三項「計畫、評審、返工（修復問題）」，如果參與評審的人對評審的內容還不是很熟悉，則會在評審前插入「介紹、預審」，如果評審的內容較多，評審活動還會延長，所以完整的流程可以這樣「計畫、介紹、預審、評審、延長、返工」。
在計畫過程中，會有前期的準備、輸出計畫安排、時間進度表、評審材料的整理；軟體生產過程評審的參與人一般有作者、講解人、pm、評審組長（pl、ba/se等）、組員（開發、測試等）、記錄員；評審過程中會記錄評審問題、評審結論；返工則是修復問題或發出影響評估報告（例外報告）。
那麼回到軟體生產各環節，都會評審下面這些內容：
需求階段評審點：評審需求清單、交付特性、設計需求、專案計畫等內容；
設計階段評審點：評審產品設計規格、story設計文件、概要設計/詳細設計等；
開發階段評審點：要求開發自測（自我評審**、ut）、**評審；
轉測試階段評審點：主要評審功能是否實現、主流程是否暢通不阻塞測試、轉測試質量評估；
測試的評審點：除了集中在後期的測試，在需求階段還會評審測試策略、測試用例，後期主要是開展sit、svt；
上線評審點：上線質量評估、使用者驗證測試、資料的評審。
通過上面這些內容，可以看出評審活動是保證質量的重要手段，身為質量人員，除了要能夠正確牽引團隊流程規範的開展評審，過程中還應參與到評審中去了解評審活動開展的細節，是真的發現問題起到了成效，還是流於形式，做表面工作。
最後，再次提一句，無論把「評審」叫做「檢查」「檢視」「review」，都不能忘了其根本目的是為了盡早發現問題，修復缺陷，避免錯誤流出到下個環節！
需求評審 SPEC評審 用例評審 歸檔用例
本文部分內容借鑑於部落格需求評審的關注點 1 評審前期準備 評審是要在寫 前發現問題，不要吝嗇將時間花在前期上，因為這會大大減少我們中後期的意外，避免做很多的無用功。在評審之前，我們要仔細閱讀相關的評審資料，了解每個點是幹什麼的。2 評審中需要關注的點 1 文筆 描述是否存在錯別字，特別是介面上的文...
軟體需求評審 軟體適航QA集
1.什麼是引數資料項檔案 parameter data item file 舉個例子，有時候我們做軟體的時候，有可能軟體本身用到的一些引數會經常變動，針對這些引數，常見的有三種做法。第一，最不方便的做法，把這些引數在程式中寫死，每次修改引數的時候開啟源 進行修改，其實這種做法在 格式比較規範 修改又...
需求評審與需求測試
在軟體開發過程中，需求分析是最開始的工作，需求分析如果做得不夠詳細或者是偏離使用者需求的話，往往會給專案帶來滅絕性的災難。因此如何保證需求分析的正確性，不偏離使用者的需求就成了決定軟體專案成敗的關鍵。需求工程師取得使用者的顯性需求後，要仔細的分析使用者到底要求軟體實現什麼功能，使用者的表達和需求工程...