一家航空公司A的信息技術部下設一個10人的QA團隊，主要職責是制定項目管理流程、監控項目質量、考覈PM流程執行情況。
另一家航空公司下屬的軟件公司B，剛入職了一個QA。他的第一項工作任務，是準備軟件著作權和高新技術企業的申報文件。
兩家公司，兩種QA。親，你怎們看？
軟件開發的衆多角色中，唯有QA，是被扭曲的最嚴重的。我訪問過幾個QA，他們是這樣看待自己的工作的：
Vicky：“QA必須要像一個開發一樣思考，理解業務邏輯和代碼實現細節。”
Patrick：“程序員每次都懟我，說一個外部人員怎麼可能理解項目的情況。”
Sam：“QA = 測試 + 打雜。”
Cherry：“我剛畢業一年，什麼也不懂，每次跟項目組溝通都很心虛。”
……
🤷🤷🤷🤷🤷
我非常理解項目團隊都不願在百忙之中，還被人指手畫腳。可如果你去潛水，一邊穿裝備，一邊被教練檢查，你一定十分樂意。因爲，教練的檢查，進一步保障了你的安全。QA檢查也是一樣的道理，不是因爲不信任，而是要再次確認，提高“安全係數”。
在我們不否認檢查的必要性後，接下來要解決的就是WHO和HOW了。
WHO
因此，QA的質量保障工作，是通過直接保證軟件開發過程的質量，來間接保障項目的質量：
- 確保軟件開發過程和過程中的產出，與定義的標準、規程的要求是完全一致的
- 確保能及時發現過程、產品，甚至是標準和規程中的不足，並提醒管理者及時改進
千萬不要被QA的名字所迷惑。軟件的生產者，纔是唯一能保證質量的人。QA的工作是監督那些對質量負責的人，提醒他們注意實際情況與標準之間的偏差，在產品交付之前解決質量問題。否則，QA就會變成成本高昂的無用功。
你可能要反駁我了：實施Scrum敏捷的時候，壓根不需要QA！那麼請問，在Scrum中，誰來保證團隊按照流程來執行？回答當然是敏捷教練（CSM）。既然敏捷教練在負責團隊按照流程執行，那麼CSM就是Scrum裏的QA！
HOW
如何才能讓QA發揮作用，突破高質量軟件開發過程中的障礙呢？勝任QA一職，需要具備哪些主要能力呢？
- 對項目計劃和從屬計劃的完整性進行評審
- 參與需求、設計和代碼的審計
- 對所有測試結果進行評審
- 定時審查配置管理的執行情況，以確定是否符合標準
- 參與項目的階段評審，爲何沒有達到合理的標準與規程要求，需要記錄不符合項
- 定期審覈過程、標準與規程是否滿足項目的需求
- ……
從廣度上來說，上述列舉覆蓋了軟件開發的整個週期。從深度上來說，QA可能是一個人，但做好QA需要一羣人，尤其是高層管理者。如果高層管理者有決心，在項目組沒有解決QA問題之前，不允許交付的話，那麼QA就可以幫助管理者不斷改進產品質量，獲得更高的效率和客戶滿意度。
上圖是比較理想的組織架構。之所以理想，是在於以下三個方面：
1. 質量與研發平起平坐。項目執行很重要，但項目的質量保障和質量改進也同樣重要。
2. 獨立於項目組的質量部，是QA工作客觀性的保障。
3. 上面兩點衍生出了第三點，質量與研發的平衡關係，是QA和PM需要共同努力的方向。QA要改進審計工作，讓項目團隊不反感；且可從中獲益。PM要讓項目團隊明白質量和改進的意義，處理好QA提交的問題與不符合項。
說完了QA的What、Who、How後，我們來重新看一下開篇的例子。
B公司的做法顯然是極不成熟的，但恐怕是很多公司發展過程中不可避免的。這種情況，需要意識上的覺醒，認識到過程決定質量後，纔會慢慢改善。
那A公司呢？你可能會覺得A公司的QA太重了。從質量的角度出發，這一點我倒不覺得是問題。真正的問題是A公司的QA直接參與PM的考覈，打破了與項目組之間應有的平衡關係。這會導致項目組爲了QA而QA，把改進變成了負擔。