誰說了算？如何消除把關現象並提高質量

Jonny Steiner，產品行銷經理

 

我們相信你肯定有過類似的經歷：你在公共場合閒逛，偶然看到一個年輕人穿著你最喜歡的樂團的T卹。你最初的反應可能是這樣的：「哇，涅槃樂團的T卹？不知道他們會不會唱涅槃的歌。」 是不是很熟悉？如果是這樣，恭喜你，你已經具備了「把關人」的潛質！我們說“潛性”，是因為無論如何，你都不應該上前盤問別人穿涅槃樂隊T恤的權利。這篇部落格文章免費為你提供了一條人生經驗。

好了，泛泛而談就到此為止，我們今天要討論的是與品質保證和測試團隊相關的把關人角色。在軟體開發領域，把關人是指掌控軟體或更新何時可以上線的人員。這意味著，在這種情況下，把關人承擔著軟體品質的全部責任。通常，這個角色由測試或品質保證團隊中的專職成員擔任。

誰 Release是的 Releases?

人們通常會在批准發佈時詢問測試人員的意見。測試人員和開發人員在參與過一些專案後常常感到沮喪，因為在這些專案中，品質保證（QA）團隊掌握著發布的關鍵權力。將如此重大的責任賦予一個團隊可能會導致糾紛和延誤。

在某種程度上，測試團隊對這個身份感到自豪，因為它賦予了他們很大的權力。然而，這確實引出了一個問題：為什麼品質保證或測試團隊需要批准發布？當然，我並非有意貶低品質保證或測試團隊。我們都知道，在困難的情況下，這些團隊總是盡其所能，保持良好的態度和冷靜。

另一方面，讓測試人員擔任最終發布決定者的角色，會給他們帶來很大的壓力。

讓我們來看看讓品質保證部門把關會帶來哪些負面影響：

• 所有瓶頸—— 開發團隊通常由五人組成，其中一人被指定為「測試人員」。顯而易見，讓一個人負責測試和品質可以節省大量成本。 領導 瓶頸。
• 承擔主要責任—— 指定一人負責產品發布意味著其他團隊成員會錯誤地認為所有缺陷都會在品質保證階段被發現。更糟的是，這還會讓他們有藉口推卸責任，因為他們可以簡單地把責任推給品質保證團隊，從而逃避對任何進入生產環境的缺陷的責任。
• 沒有人是完美的，就連測試人員也不例外—— 最好不要把整個發布流程都建立在一個人的發現之上。 全部 那些蟲子。它們和你一樣都是人，人都會犯錯。
• 回饋迴路—— 在守門人模式中，當開發者完成他們在專案中的部分時 處理， 他們將專案交給測試人員或品質保證人員，然後繼續進行下一個專案。然而，當不可避免的回饋到來時… 在， 他們需要切換回之前的功能。這可能會導致大量半途而廢的項目堆積成山。

守門制度的替代方案是打破守門制度。

有一些測試方法可以確保發布高品質的應用程序，而無需任何中間環節。如果將品質保證 (QA) 的工作交給整個開發團隊，那麼他們所有人都會對品質負責。 QA 團隊仍可負責測試工作，但測試工作量會更大，其他團隊成員也可以提供協助。

• 開發人員可以透過編寫自己的單元測試來覆蓋他們所做的工作。
• 產品經理可以檢查測試環境，以確保新功能能如預期運作。
• DevOps 管理人員可以使用持續整合系統來監控每次提交新程式碼時的測試情況。

你可以很輕鬆地開始實施這種做法。

在新功能開發工作開始之前，先召開一次會議。這樣，開發人員和測試人員就能在正式開始迭代開發之前，清楚了解他們需要做什麼來驗證工作是否符合驗收標準。由於工作內容事先已經討論過，團隊的工作量就能均衡分配；開發人員負責編寫 API 測試，而測試人員則可以專注於 UI 和功能測試。

隨著專案推進，團隊如果發現需要解決的問題，可以進行內部討論，也可以跨團隊討論。例如，如果品質保證團隊發現缺陷，可以與產品開發團隊溝通，確定是否需要立即處理，還是可以稍後再處理。

更棒的是，隨著更多人參與專案並進行測試，會形成一種「左移」思維，即測試在流程早期階段就盡可能地進行。無需等待特定時間點即可開始測試，它自然而然地成為人們日常工作的一部分。從長遠來看，這應該有助於最大限度地降低開發週期後期的風險。

最終，這會帶來更多測試，從而提高測試覆蓋率，因為它促使跨學科團隊相互溝通，而不是各自為政。如果你的組織有團隊孤立問題，你甚至可以與產品負責人和利害關係人討論這個問題。在處理把關人問題時，促進溝通與協作至關重要。

結果將如下所示：

• 共同責任—— 由於沒有個人負責，整個團隊共同承擔交付高品質軟體的責任。
• 告別瓶頸—— 現在不再是一個人獨自進行全球測試了。透過所有人的參與，新版本和應用程式將更快地投入生產環境。
• 收緊回饋迴路—— 發現缺陷後無需再進行上下文切換。缺陷將在流程早期被發現並修復，從而避免對生產造成任何延誤。

QA 中的把關制度已成歷史遺跡

這種情況在一些組織中仍然存在。品質保證（QA）部門負責專案的發布，並掌握著發布的金鑰。這種有害的做法會給測試人員帶來壓力，並導致各自為政的團隊之間關係惡化，因為他們各自為政地朝著同一個目標努力，卻缺乏協作。

實施品質保證把關時主要會出現兩種負面狀況：

1. 項目延期—— 品質保證部門會在發布前排除一些小問題。
2. 生產缺陷—— 每當出現漏洞時，品質保證部門就會成為替罪羔羊，因為他們被認為對整體品質負責。

為了摒棄這種過時且說實話不利於協作的開發和測試方法，團隊需要讓專案中的所有成員在開發過程中參與測試，而不是僅僅由品質保證（QA）部門負責所有測試工作。他們還需要將測試工作左移，儘早並頻繁地進行測試。了解這些基本概念將有助於組織建立一個讓每個人都能各司其職的系統，從而提升整體發布品質。

品質作為目標和理念，必須成為團隊工作流程的基本要素之一。它也必須是專案所有參與者共同努力的目標。如果你發現公司內部出現團隊間各自為政或缺乏合作的情況，就應該及時與相關負責人溝通，讓他們有機會改變現狀。如果品質保證團隊只專注於把關，那麼整個應用程式的品質就會受到影響，這實在令人遺憾，因為他們的職責恰恰就是把關。