測試是否需要一票否決權

某業務團隊的測試人員在迭代的末期，發現還有很多缺陷未修復，原則上達不到上線要求，那麼，他應該如何處理？如果你是測試負責人，要如何處理？測試人員是否需要有決定上線的權利呢？

在做質量保障體系的時候，有很多測試人員從質量的角度出發，提出了這麼個問題。本文聊聊個人的理解。

01 什麼是質量

這是一個複雜問題，很多東西可以算作軟體的質量。

從使用者介面的角度來看：它是否能便捷地引導我完成某項任務，使我更有效率且不會遇到阻礙？從可靠性的角度來看：它是否包含導致錯誤和崩潰的缺陷？

從架構的角度來看：原始碼是否分為明確的模組，以便程式設計師可以輕鬆找到並理解本週需要處理的程式碼？

我們當前講的質量基本上都是外部質量，因為那是客戶最直觀的感受，也願意為更好的介面，更友好交付買單。

但是客戶並不會為內部質量買單，因為他們無法感知軟體內部模組化的結構，更不用說判斷它的好壞。既然如此，為什麼軟體開發者要花時間和精力來提高軟體的內部質量呢？

另外，從研發的角度上看，內部質量從長期看，會極大地提升後續的交付效率，高內部質量可以最小化技術債，使得新增新功能的工作量、時間和成本都更少。但團隊往往不一定能等到那個時候，這也是為什麼重構、單元測試這類的技術比較難在團隊中落地的一個重要原因。

#02 為什麼質量可以被取捨

專案管理的基本 4 要素：範圍、時間、成本、質量。通常我們都在討論時間、範圍和成本，預設質量是必要的，但是實際上，時間和範圍在多數情況下，更會被管理者或者市場固定。

傳統專案中，強調的是範圍固定，成本和時間是可以調整的；

在敏捷的語境下，強調交付節奏固定，範圍是可以調整的；

但是現在的大多數專案，是既要也要，範圍、成本、時間都是固定的！！（如果你的團隊能夠完善遵循某一種研發模式，也是幸福的。當然這個中的原因，有可能是領導不懂，也有可能是市場不等人，也有可能有其他的原因）

那怎麼辦？只能犧牲質量，否則專案就肯定崩潰。

因為，質量是可以在事後來彌補或者應對的。雖然成本可能會更高，但是相對於交付節點（市場原因、合同原因等），還是輕一些，因為如果不能按時交付，那就是 0（特別是 ToB 的業務，質量是可以透過商務解決的，但是不交付，那是不可接受的）。

當然，如果你的團隊重視質量，並以質量為第一要素，那隻能說恭喜你。你是幸福的。

（關於交付時間與交付質量的案例，另開文章再討論，不在本文的討論範圍）

03 一票否決權能解決問題嗎？

先說結論：哪怕給了測試這個權利，你也行使不了。

首先，測試不是質量的生產者，只是質量的監管者。測試很難從根本上去解決質量的問題，不論是左移還是自動化，都是為了更好地協助研發，提升交付質量，但不是決定性因素。

其次，權責不對等。產品能決定業務是否上線，是因為產品對最終的交付結果負責，對產品的成功失敗、運營資料負責。但是沒有哪個專案失敗了，會說是因為測試不到位，把測試開了的。前期的產品調研、使用者訪談、競品分析等，都是產品在跟進的。所以只有產品才能決定迭代是否上線。

04 測試能做什麼？

那麼，在質量可以被取捨的情況下，測試能夠做什麼？

在筆者的團隊中，筆者在稽核測試報告的時候，非常重要的一項內容，就是風險評估。

對於測試負責人，在出具測試報告的時候，必須學會對交付的版本做對應的風險評估：

識別風險：經過這段時間的測試，現在如果發版本，會有什麼樣的風險？可以從質量、配置、影響範圍，甚至是發展過程來識別風險；

給出可能的方案：在有效識別風險的情況下，需要給出一些解決方案，有是最好的，沒有不強求。

及時上報：除了在測試報告中體現風險外，在迭代快結束的時候，是否及時把風險上報給團隊負責人或者專案組，透明資訊，為專案組做決策，提供依據。

識別風險，比一票否決，更能體現測試的價值。

05 在研發的哪個環節可以做強卡控

在整體的研發過程中，其實有一個環節，測試可以做得很強勢，那就是研發移測的 Showcase 環節。

在 Showcase 環節，測試可以提供 P0 級的測試用例，讓開發做對應的執行並標註結果，如果測試不透過，則不允許轉測。

這樣做可以有效地提升研發的移測質量，保障測試活動的正常進行。同時對於研發而言，也是有利的，因為在這個時間節點修復缺陷的成本是最低的。

06 小結

由於權責不對等，所以測試人員沒必要強求一票否決的權利（通常也落地不了）。把更多的精力放在提升研發的移測質量上，同時在迭代後期，有效地識別出質量風險，給專案組提供決策依據，會更合理些。

共勉。