經常有這么一個問題：QA為什么對過程改進有幫助。答案當然與如何理解、如何管理、如何處理QA與項目之間的關系密不可分。這里有很多議素我們需要好好探討。其中一個比較實在一點的，就是如何讓QA可以在審核之中，發現項目是否遵從標準規程之余，還能否發現可以提高項目效率的機會，并且提出有針對性地建議，讓項目可以更有效地達成項目的目標。
QA審核的內容，通常都可以從審核的檢查單之中看到一個端倪。如果檢查單里的問題，他們的答案明顯與項目的效能無關的，按照這樣的檢查單審核，就當然不能發現如何幫助項目提高效能。所以我提到QA需要制定“有效性”的檢查單。
問題立刻出現了，就是“什么樣的檢查單才是有效性的檢查單？”本文的目的就是希望解答這個問題。
讓我首先作幾個聲明：
1）當我們談“有效性”審核的時候，我們不是說“遵從性”的審核不好。我希望強調一點：“遵從性”是制度化與成熟程度的基礎。沒有了遵從性的團隊、組織，是不成熟的，過程操作一般是低效的。只有具備了一定程度上的遵從性，過程管理才能開始生效。請大家明白這一點。
所以我們談有效性審核，其實是說在遵從性審核的基礎上，考慮有效性的問題。這是一個能力水平的提升，而不是一個對標準規程的叛逆。
2）要提升過程的效能，因為每一個項目團隊能力、風格不一樣，是需要針對性的。這些針對性，就反映在調整檢查單上面。我也遇到過這樣的問題：“QA的標準規程里有標準的檢查單，我們是否必須者用同樣的檢查單，才是符合標準的QA審核？”
我希望說明的就是：在符合標準要求的情況下，進行部分的調整是可以容許的。這個概念，就體現在
CMMI 要求標準規程里提供“適配”，并要求制定適配的準則。我們需要了解這一點。當然這個需要對規程與過程管理具備一定的了解與判斷能力。這些知識與經驗是需要積累的。
3）千萬不要認為只有一個方法制定檢查單。做任何事情，都有很多實際方法、途徑可以完成。這里只是一個案例。我希望大家可以看到要考慮什么問題，要如何思維，然后發展自己的觀察、分析、判斷等能力，這才是最重要的。
好了，我們就談談如何制定“有效性”的檢查單吧。我拿了一個案例來說明。這個案例是一個組織在使用的，用來審核“估算”的標準檢查單。這里就來說明如何從這個檢查單開始，加入“有效性”因素的考慮，來達到一個既滿足本來的遵從性審核任務，也可以反映項目的操作是否有效的檢查單。
制定有效性檢查單的步驟：
1）我們要知道，“有效性”就是能夠達到目標。如果沒有目標，或是QA不清楚目標，有效性是無從談起的。
所以QA一定需要知道檢查單上面每一個條款，如何與項目的目標相關聯。
2）符合性與有效性既相互關連，也相互獨立。如果要過程有效，我們需要建立制度化。制度化的一個條件，就是每一個員工都需要有愿意遵從規程，符合規程的意愿。我們需要用一種大家都了解的，一致的方法，來處理日常的、或是不理想的、特殊的情況。要過程改進，我們就需要有遵從的紀律。
所以有效性是建立在“遵從、符合”的基礎上的。
另一方面，如果規程制定得不合理，或是缺乏靈活性，來適應不同的項目、技術、產品。比如，無論項目大小，周期長短，都要求用“Wideband Delphi”進行估算。這就不靈活了。短周期的小項目就很不適合了。又或是要求嚴格復雜的
測試用例分析、策劃等等，也有同樣的問題。那么，項目的過程就是符合，也不會有效。
所以QA需要具備專業態度與獨立精神來處理現實中“符合性”與“有效性”的沖突與一致。
3）因為過程有效性，就是能夠達到目標。那么，審核過程的有效性，就需要判斷。所以一定要求審核的人（QA）具備這種判斷能力，而不是期待把檢查單細化到沒有判斷能力的人也可以實施。
舉一個例子，如果檢查單里的問題是：
一）估算是否按計劃的時間完成？ 那么誰都可以判斷。但這不是有效性的。因為我們沒有考慮不按計劃的時間完成是否影響項目的目標。
二）估算完成的時間是否對項目達成目標造成風險？這個問題才是有效性的。那么，就需要判斷了。我們不能夠有效地定義：超時兩天就可以，三天就不可以。這在大部分的情況底下其實是不可能的。能夠回答這類問題的人，需要有判斷能力。
這是為什么我們要求QA不斷提高自己的能力的原因。
談到QA能力，我在這里先問一下：我們可否識別“子過程的目標”與“審核子過程的目標”？我們需要能夠分辨這個。舉一個例子：“同級評審”的目標，就是發現缺陷。但是為什么我們要審核“同級評審”這個子過程？那么目標就可以有很多：比如，作為考核的依據；查看項目是否遵從標準規程；評價這個子過程的操作實效；發現項目是否具備實施同級評審的技巧，等等。我們一定要能夠分辨這些不同層次的目標。
4）總結一下：要從事有效性的審核也好，制定有效的規程也好，就需要考慮：
每一個條款或是步驟是為什么，要解決什么問題？ （要解決什么？）
這個條款或是步驟有什么后果？ （有什么后果？）
這些要解決的問題與實施后果如何影響項目的目標？（對項目的影響與風險）
這些就是QA需要能夠回答的問題。
QA需要養成一個考慮這些問題的習慣來建立自己回答這些問題的能力。
5）假設我們已經具備這些能力，那么制定有效性的檢查單就不難了。第一個考慮的概念，就是“層次”。假設EPG提交了一個檢查單，如下：
檢查項包括：
是否按時進行了二次估算？
作者是否參與集成測試活動估算？
作者是否參與各模塊開發活動估算？
開發相關人員是否都參與集成測試活動估算？
是否會議方式估算？
詳細設計估算是否完整有效？
編碼估算是否完整有效？
單元測試估算是否完整有效？
集成測試用例估算是否完整有效？
集成測試執行估算是否完整有效？
偏差超過約定的偏差值是否再次估算？
是否完整填寫估算人員姓名及過程數據？
估算報告是否及時歸檔？
我們可以看到，這個單里的條款，它們的重要性不是同一個層次的。這不是一個制定任何規程的好習慣。我們需要知道把同一個層次的條項羅列在同一個層面上。比如：
是否按時進行了二次估算？
作者是否參與集成測試活動估算？
有哪些與這個估算相關的活動？
作者是否參與各模塊開發活動估算？
開發相關人員是否都參與集成測試活動估算？
是否會議方式估算？
有哪些與這個估算相關的績效？
詳細設計估算是否完整有效？
編碼估算是否完整有效？
單元測試估算是否完整有效？
集成測試用例估算是否完整有效？
集成測試執行估算是否完整有效？
偏差超過約定的偏差值是否再次估算？
估算報告是否及時歸檔？
層次這個概念在很多地方都有應用。看看我們公司的結構，你就可以體會到層次的普遍應用程度。不同層次的，就不會在同一個級別的領導之下。比如，生產、財務、市場都是在同一個層次上。我們不會把“融資”放在同一個層次，它一定是在財務底下的。
層次會影響效率。比如我們的檢查單，合理的層次，會讓員工與QA更明確各個部分的重要性，在開展工作的時候也可以更好地掌握注意力。
要了解層次，可以這樣看：同一個層次的，是比較相對獨立，互不影響的。低一個層次的，是它上面層次的一部分，或者說，是會對上面層次的提供貢獻。比如：“是否按時進行了二次估算？”和“有哪些與這個估算相關的活動？”是相對獨立的。但“作者是否參與各模塊開發活動估算？”就是與估算相關的活動之一。這個有點像CMMI的級別定義原則。這些都是幫助有效的理念，并且被廣泛應用在過程管理與以外的很多方面的。
檢查單的組織可以考慮條項的層次。
如果不了解這個“層次”的觀念，就請你提問。我們務必交流清楚。
6）下一步就是分辨符合性與有效性。還記得上面提到的三個考慮么：
每一個條款或是步驟是為什么，要解決什么問題？（要解決什么？）
這個條款或是步驟有什么后果？ （有什么后果？）
這些要解決的問題與實施后果如何影響項目的目標？（對項目的影響與風險）
我們要知道，如果問題是：
是否按時進行了二次估算？
我們的答案就會是“是”或是“否”。這個問題要解決的，就是：你是否遵從計劃？是一個符合性的問題。所以解答這個問題一點都不難。但是如果問題是：
完成二次估算的時間對項目有什么影響？
這個問題要知道完成時間對項目有什么影響，要知道估算知否有效。這才是有效性的檢查項。回答這個問題就一點都不簡單。我們要知道這個完成時間有什么后果。早于計劃的要求完成？按計劃時間要求完成？超時了？超了一點點？超了很多？還有更厲害的：這個模塊/任務是否在關鍵路徑上面？我們要知道所有這些，可能還有其他的，才能作一個判斷。做這個判斷，就要知道關鍵因素與它們的后果。比如：
估算晚了兩個星期。但這是一個2 年的項目，而且這個任務可以有5 個星期的靈活性。那么，這樣晚了兩個星期的作用就不很大。他是不符合。但后果不大。
如果估算晚了兩個星期，項目是2 年的項目，而且任務是在關鍵路徑上。后果就可能讓項目延誤兩星期。是大概2 %的延誤。這樣的延誤，絕大部分客戶可能發現（重要），但都不會太計較的（不嚴重）。
如果估算晚了兩天，任務在關鍵路徑，項目是2個月的項目。這樣問題就嚴重好多了。
所以如果要作有效性審核，我們需要知道關鍵因素，以及他們的后果。
一個步驟的目的，如果單單是看項目是否符合，而不考慮后果的，這樣的管理，目的就是在于“限制行為”。限制或是規范行為的壞處，就是引起項目的抗拒。所以“限制行為”的管理很難有好效果的。
7）那么，我們可以開始把這些關鍵因素組織一下，為把檢查單改變成為有效性的檢查單做準備。我們需要把原本的改成符合與有效兼顧，并且增加一些遺漏的關鍵因素。首先，我們可以把下面的條項：
是否按時進行了二次估算？
作者是否參與集成測試活動估算？
有哪些與這個估算相關的活動？
作者是否參與各模塊開發活動估算？
開發相關人員是否都參與集成測試活動估算？
是否會議方式估算？
有哪些與這個估算相關的績效？
詳細設計估算是否完整有效？
編碼估算是否完整有效？
單元測試估算是否完整有效？
集成測試用例估算是否完整有效？
集成測試執行估算是否完整有效？
偏差超過約定的偏差值是否再次估算？
估算報告是否及時歸檔？
小心看一下，用提高效率的觀點，考慮每一個條項的后果，改編成有效性的條款，如下：
估算完成的時間對項目的影響：
作者樂于承諾估算結果的程度與原因：
（暫時忽略）
估算的方法與過程保證了估算的合理性：
（暫時忽略）
（暫時忽略）
估算結果得到維護與使用：（包含了“估算報告是否及時歸檔？”）
我們現在加入我提到的三個因素：
負責任務的人親自牽頭估算
大家（項目組與客戶）對任務范圍與內容的認識是一致的。
方法與參考數據的使用是合理的
檢查單就變成：（斜字代表這個步驟新加進來的。）
估算完成時間對項目的影響：
作者樂于承諾估算結果的程度與原因：
負責任務的人牽頭估算
估算的方法與過程保證了估算的合理性：
大家對任務范圍與內容有一致的認識
估算方法適合項目要求
方法的調整是合理的
估算結果得到維護與使用：
項目計劃使用了估算結果來安排任務
如果需要，可以把原來的符合性的放回去。可以把它們放在另一個部分，也可以把它們放在適合的層次。比如：
估算完成得時間對項目的影響：
· 是否按時進行了二次估算？
作者樂于承諾估算結果的程度與原因:
· 負責任務的人牽頭估算
估算的方法與過程保證了估算的合理性:
· 大家對任務范圍與內容有一致的認識
· 估算方法適合項目要求
· 方法的調整是合理的
· 是否會議方式估算？
· 作者是否參與各模塊開發活動估算？
· 開發相關人員是否都參與集成測試活動估算
· （如果用Delphi方法）偏差超過約定的偏差值是否再次估算？
估算結果得到維護與使用：
· 估算結果在計劃里項目計劃使用了估算結果來安排任務
· 估算報告是否及時歸檔？
以往估算的績效：
· 詳細設計估算是否完整有效？
· 編碼估算是否完整有效？
· 單元測試估算是否完整有效？
· 集成測試用例估算是否完整有效？
· 集成測試執行估算是否完整有效？
現在的檢查單包含了本來的條項，也包括了從有效性的角度的內容。但有效性方面還是不充分的。所以我們需要每一個條項都問這個問題：
我如何可以判斷這些條項的有效程度？這個也需要我們了解過程的關鍵因素！
上面已經提到過估算的完成時間如何影響項目。包括延誤的比率、客戶的要求、任務是否在關鍵路徑等等。其他的，我就把我考慮的加到相關的條項底下，如下：
估算完成得時間對項目的影響：
· 是否按時進行了二次估算？
· 延誤程度對比項目的里程碑與周期的影響有多嚴重
· 延誤如何對比任務的關鍵路徑寬容時間
· 考慮這個任務的關鍵性與項目對它的依賴程度
作者樂于承諾估算結果的程度與原因:
· 負責任務的人牽頭估算
· 判斷負責人對結果的信心
· 查看負責人以前的承諾（按時完成任務）表現
估算的方法與過程保證了估算的合理性:
· 大家對任務范圍與內容有一致的認識
o 在如下面兩條羅列的估算活動以及其他情況底下，多方面的干系人的表達是一致的。
o 如果有開估算會議，討論覆蓋足夠的內容與議素，但進行順利，沒有理解不一致的跡象。
o （還可以有其他的蛛絲馬跡來判斷）
· 估算方法的效能適合項目的目標
· 參考與使用的歷史數據與對比、調整的合理性
· 是否會議方式估算？
· 作者是否參與各模塊開發活動估算？
· 開發相關人員是否都參與集成測試活動估算？
· 偏差超過約定的偏差值是否再次估算？
估算結果得到維護與使用：
· 項目計劃使用了估算結果來安排任務
· 項目明確有哪些活動受這個估算結果影響（可以更好處理將來的延誤）
· 估算報告是否及時歸檔？
以往估算的績效：
· 詳細設計估算是否完整有效？
· 編碼估算是否完整有效？
· 單元測試估算是否完整有效？
· 集成測試用例估算是否完整有效？
· 集成測試執行估算是否完整有效？
希望大家可以關注到這里檢查點之間的關聯性，以及我們的步驟如何影響項目的專注。
8）上面的表就是一個從你們本來使用的檢查單，增加了審核有效性的角度而得來的。讓我們把這個資料放到一個表格里：
大家可以補充“檢查方法”這一列。大家也可以按這個思路，增、減因素與檢查項的內容與細節。其實標準的檢查單，也應該可以讓大家按情況“調整”。請留意，我不說修改，而說調整，含義是：我們需要按標準的思路，讓它更有效，而不是把內容隨意變動。我說的明白么？
這樣的表格跟以前的有兩個分別：
語氣是開放式的，不鼓勵是否地打勾。每填一個條項，都希望QA知道需要明白后果。以后習慣了這樣思維，我們就可以不那么關注語氣的問題了。我鼓勵大家目前還是在意一點比較好。
內容多了一些有效性的關鍵因素。這個是可以積累的。我們需要從工作中觀察，以需要多討論，多交流，多看書。一位QA發現一個關鍵因素之后，不能單單加到自己的檢查單里。QA小組最好組織討論會議，讓每一位QA都知道一個關鍵因素的來龍去脈，原因后果。這樣才能讓QA團隊的經驗建立起來。
也請留意，每一個關鍵因素都有數個檢查項，但對項目來說，同一個關鍵因素的所有檢查項加起來只有一個后果，我們不單單在乎是否打勾，而是要判斷項目的表現有什么后果。我們可以按關鍵因素預設一些后果。比如：超越預期、沒有風險、有可承擔的風險、有不可承擔的風險、不可承擔又不可緩解的風險等。項目的操作狀態，就是這幾個關鍵因素的執行后果。每一個關鍵因素的后果，都取決于它下面的檢查項。但我以前也說過，我覺得每一項打分，然后加起來，不是一個很好的方法，因為有些條項的重要性，會因為其他的條項內容而改變的。我們可以這樣做，然后參考那些分數。只是不要把分數看成決定一切就可以了。
想象一下，如果我們的QA審核報告都是這樣的，大家就會越來越清楚如何提高項目的效率。將來的過程問題，大部分都可以從QA報告的歷史資料找到答案。過程改進將會變得非常容易。
9）不要以為這是唯一的有效性檢查單，所以不要把這個看成經典。有效性的檢查單可以有很多。比如，我們如果不一定要求從你們本來的檢查單開始，我們可以從我提到的三個因素開始。那么，檢查單就會不一樣。
我們要能夠分辨得細一點，要爭取了解細一點的議素。比如，不要把上面的檢查單看成固定不變的。但也不要以為什么事情都不能是固定的。有些事情固定了，就不靈活，不能適應不同的情況，效果就不好。有些事情是不會改變的，改了，就沒有效果了。如何判斷呢？
基本上：
因果關系是不會變的。沒有了因，就不會有果。
解決方案，就幾乎永遠都會有不同的方案，達到相同或是接近的效果。
要進步，我們就要慢慢掌握這些理念，并且能夠把它應用到自己的工作上。