testing

微軟的品質保證之道

微軟曾首創 SDET 職位，後將其與開發人員合併，提升軟體品質和團隊效率。

原文: How Microsoft does Quality Assurance (QA)
作者: Gergely Orosz

微軟在軟體品質保證領域的發展和重要性上扮演了舉足輕重的角色，率先設立專職測試職位，超越傳統手動測試。本文將探討：

SDET 的角色
SDET 的退場

SDET 角色

SDET（軟體測試開發工程師）是微軟在科技業首創的職位，負責撰寫自動化測試、建置和維護測試系統。 SDET 與 SDE（軟體開發工程師）的唯一差別是 SDET 通常不寫產品程式碼，而是在同一團隊中撰寫測試程式碼。

雖然難以追溯 SDET 確切的誕生時間，但很可能是在 1990 年代。以下是一位微軟 Exchange 團隊成員在 2004 年對 SDET 的工作內容說明：

「SDET 是在測試團隊而非開發團隊中工作的開發人員。 SDET 兼具測試人員的敏銳度與對程式碼的熱愛，而且寫很多程式碼。

SDET 為測試團隊提供必要的工具和流程，讓測試人員能充分發揮其專長，在產品上市前徹底測試，找出所有潛在的錯誤。

SDET 能分析產品功能和架構，設計並實作出能協助測試的工具。

SDET 喜歡短週期的專案，一年內會設計、實作許多工具和測試框架，使用最新技術，並有很大的創新空間。

雖然產品品質至關重要，但 SDET 不像開發人員在產品週期末承受巨大壓力。簡單來說，SDET 很少需要為後果負責。」

微軟也為 SDET 規劃了正式的職涯發展路徑。同篇文章提到：

「SDET 的職涯發展空間很大。如果您熱愛 SDET 的工作，可以往測試架構師發展；如果您想往管理方向發展，可以晉升為 SDET 主管，甚至測試經理。

如果您只想寫程式不想參與測試，可以轉換跑道成為開發人員，很多人選擇這條路。但如果您發現自己熱愛測試工作，也可以成為測試人員。」

在 2014 年以前，微軟團隊的 SDE 與 SDET 比例通常是 2:1。 2012 年我加入 Skype for Xbox One 團隊時就是如此。當時團隊成員組成為：

12 位 SDE
6 位 SDET
2 位 PM（產品經理）
1 位 EM（工程經理）
1 位 SDET 主管

在我們的專案中，SDET 團隊負責所有測試工作：

手動驗證開發人員建置的功能是否符合預期，包含邊緣案例
建置整合測試和端對端測試，自動化測試流程
制定手動測試計畫，並在重要里程碑前執行
參與功能規劃階段，提出邊緣案例的構想以及驗證方式
為棘手的問題提供解決方案，例如如何在 Xbox 硬體上進行 Skype 產品的效能基準測試

單元測試一開始是個爭議點，誰該負責寫？有些來自遊戲業的資深開發人員通常不寫自動化測試，他們認為任何自動化測試（包含單元測試）都應該由 SDET 負責。

然而，我與其他有應用程式開發或測試驅動開發 (TDD) 經驗的成員認為，開發人員應自行撰寫單元測試，因為單元測試與程式碼息息相關。我就是這麼想的。

設置專職 SDET 團隊，讓開發人員很容易將單元測試「外包」出去。 坦白說，如果沒有 SDET 團隊，就不會有「誰該寫單元測試」的爭論：開發人員自然得自己寫。這是我在每個有 SDET 團隊中都會看到的 recurring debate。令人驚訝的是，今年我還聽說有矽谷公司讓測試團隊幫開發團隊寫單元測試！

最後我們團隊決定由開發人員撰寫單元測試，SDET 團隊負責其他測試工作。這個方法還算有效，但也有些問題：

「我們」和「他們」的區分造成團隊分裂。 開發人員完成功能後會交給 SDET 驗證，SDET 通常會發現問題再送回給開發人員修改。這讓開發人員感到困擾，因為這些額外的工作不在預期內。久而久之，團隊感覺像是兩個不同目標的陣營，無法朝同一個方向前進。
開發和測試之間的 issue 無限循環。 我完成功能後送交測試（丟過去），測試人員隔天發現 bug 後送回給我（丟回來），我修改 bug 後過幾天再送出（丟過去），測試人員又發現其他 bug 再送回來…如此循環往復，次數多到難以啟齒。
開發人員擅長建置複雜系統，可以大幅協助 SDET。 我們的 SDET 團隊花了數個月建置整合測試系統，進度緩慢。我們非常需要這套系統，因為手動測試耗時太長。最後，一位資深工程師建議讓開發人員加入一起建置系統。在資深開發人員的帶領下，兩週後系統就上線了。這讓我反思：如果沒有開發和測試的區分，團隊效率是否會更高？事實證明確實如此。
難以言喻的潛規則：有些開發人員輕視 SDET。 雖然並非所有人如此，但許多開發人員認為 SDET 的工作不如開發工作 challenging。 SDET 也知道轉換跑道成為開發人員會有更好的職涯發展。

結果，他們的機會很快就來了。

SDET 的退場

2014 年初，我加入 Skype for Web 團隊。這個團隊與其他 Skype 團隊不同，他們每天都會發布新版本，而不是每個月。

團隊名義上有 6 位 SDE 和 3 位 SDET。但實際上是 9 位 SDE，因為工程經理和測試主管默默決定，每天發布新版本的情況下，設置專職測試職位沒有意義。我在〈科技大廠如何執行專案以及 Scrum 的奇特缺席〉一文中提到團隊主管未公開的這項變革：

「我剛加入 Skype for Web 團隊時，我們一開始採用兩週的 sprint，遵循標準 Scrum 流程。團隊也區分軟體工程師和品保工程師。然而，我們的發布週期是兩週一次，但我們想更頻繁地發布。

我們做的第一件事就是將品保納入工程團隊。在「舊世界」裡，工程師完成工作後會提交程式碼、更新 issue，並通知品保人員可以進行審查。品保人員會在一兩天後處理 issue，審查程式碼，如果發現問題就會重新開啟 issue。這會造成很長的延遲。

我們做了一個未公開的非正式變革，所有 SDET 也開始撰寫產品程式碼，所有軟體工程師也要負責測試自己的程式碼。現在，我們不再需要等待數天才能獲得程式碼發布前的回饋。然而，雙週 sprint 和繁瑣的 Scrum 儀式成了下一個問題。」

移除 SDET 角色後，我們的生產力大幅提升！ SDET 仍主要負責測試相關工作，但也開始接手開發任務。更重要的是，我們開始大量採用結對程式設計！我記得曾和 SDET 結對開發功能：我擅長思考如何讓功能運作，SDET 則擅長指出我沒考慮到的邊緣案例。 SDET 的除錯能力也讓我驚艷。

在多數微軟團隊中，SDET 花很多時間手動測試和撰寫整合測試。但在我們團隊，幾乎沒有手動測試，大家一起建置整合測試和監控的基礎設施。開發人員或 SDET 接到任務時，會撰寫所有必要的測試，包含單元測試和整合測試，這很合理。

這項變革最大的好處就是不再有「我們」對抗「他們」。 SDET 發現 bug 後要不要修的爭論消失了，因為現在大家在產品上線前都要自己測試和修復 bug。

微軟的網頁團隊開始悄悄地移除 SDET 職位。 2014 年，我們倫敦 Skype 辦公室的網頁團隊感覺很「特別」，因為只有其他幾個網頁團隊合併了 SDET 的職能。其他團隊的 SDET 仍維持原本的工作模式。

然而，不只 Skype 部門的網頁團隊為了提升效率而整合這些職位。微軟的各個網頁團隊都獨立發現整合 SDET 和開發人員可以加快開發速度！

2014 年年中，微軟正式淘汰 SDET 職位，推出 SE 職位。 據說靈感來自微軟更大的網頁團隊 — Bing。 Ars Technica 在 2014 年的報導：

「在 Bing 團隊，撰寫程式測試的任務轉移到開發人員身上，不再由專職測試人員負責。品保部門仍然存在且很重要，但他們執行的是模擬終端使用者的「真實世界」測試，而不是程式化的自動化測試。這項改變讓 Bing 團隊在不影響整體軟體品質的前提下，更快速地發布變更。」

2014 年 7 月，微軟宣布當時規模最大的裁員，在 12.7 萬名員工中裁減 1.8 萬人，其中 Nokia 部門裁減 1.25 萬人。許多 SDET 也在這次裁員中被資遣。這與 SDET 職位退場的時間點相近，現有的 SDET 必須在接下來幾個月內轉任 SDE。 SDE 也改名為 SE — 軟體工程師。

轉型結果如何？ 據我了解，過程還算順利。對於每日發布的團隊來說，這項改變很有意義。隨著微軟也走向 SaaS 模式，每週或每月發布的團隊越來越少。當然，微軟仍然是 Windows 作業系統和 Surface 平板電腦的供應商，這兩個領域的品質策略必須與 SaaS 產品有所不同。

Visual Studio Team Services 團隊在三年後（2017 年）的回顧，很好地說明了這項變革。微軟技術院士 Brian Harry 回憶道：

「兩年前（2015 年），我們有數萬個測試案例，是由『測試人員』撰寫來測試『開發人員』的程式碼。雖然這個模式有些優點 — 例如可以明確衡量和控管測試的投資、培養測試領域的專業人才等等 — 但缺點也不少：開發人員缺乏責任感、回饋週期冗長（導入 bug、發現 bug、修復 bug）、開發人員缺乏讓程式碼「可測試」的動機、程式碼架構和測試架構的差異導致重構和調整方向的成本很高，等等。（……）

完整的測試流程幾乎要花一整天，還要花更多時間「分析結果」找出誤判，如果因為產品的正常修改導致測試失效，可能要花數天甚至數週才能修復。（……）兩年前，我們開始徹底改造測試流程。

我們將開發和測試團隊合併成單一的『工程』團隊。 我們大致上消除了寫程式和測試人員之間的區別。這不是說每個人做的工作完全相同，而是每個人都參與所有工作，並為自己產出的品質負責。我們也決定捨棄花了 8 年建立的數萬個測試案例，用全新的方式重新建置測試。」

這個團隊盤點了現有的測試類型，發現單元測試很少，但複雜且難以維護的端對端測試卻很多，因此他們決定改變這個狀況：