Re: [心得] 為什麼軟體開發者需要在意軟體品質指標

[AmosYang (Zzz...)]

※ 引述《ledia (下班後才下棋)》之銘言：
:     1. unit test 不是各處都適用
:     2. unit test 不是萬靈丹, 他只是用來取代人類重覆同一個動作容易出錯的特性
:     3. unit test 視需求再配合其他的 QA 機制

列舉一些個人經驗

* 高品質、短時程、低成本，無法兼顧
  這是定律；與稅、死亡一樣確實

* 資產與債務的共通點: 利滾利
  上述三者之中，被捨棄的那一個遲早要還的
  是故，不能總是捨棄同一樣東西, 要適度地平衡一下

* 微軟的例子 (註1)

  * 成本: 聘請 SDE 與 SDET

      SDE (software development engineer) 的主要責職是完成 shipping code

      SDET (software development engineer in test) 的主要責職是監測品質
      function, integration, security, performance, scalability,
      i18n & l10n 有的沒的通通要測

      SDE 與 SDET 的人數比約在 2:1 到 3:1 之間

      以年資、能力為基準，SDE 與 SDET 的待遇福利完全相同

      SDE 與 SDET 在工程能力的 proficiency 要求相同
      易言之，有能力受雇為 SDET 者，原本是可以拿來當 SDE 戰力用的

  * 時程

      只要你的提案方式騷到癢處 (high ROI + low initial cost)
      管理階層多半願意拿原本可以用來製造 shipping code 的時間拿來
      修正 engineering system & process 的 pain points

  * 品質

      如開頭所述，對於 engineering system & process 的投資會利滾利
      以微軟這個 product unit team 為例, 現在他們有

      * automated gated check-in 把 build break 的機會降到最低

      * automated continous integration + P0 functional test coverage
        在 commit 後約 2 hr, 一分自動產生的測試報告讓 commit owner 及
        test owner 知道有沒有任何 P0 scenario regression

      * automated continous integration + P1 functional test coverage
        在 commit 後約 8 hr, 一分自動產生的測試報告讓 commit owner 及
        test owner 知道有沒有任何 P1 scenario regression

      * automated daily integration test coverage
      * automated daily performance test coverage

        etc...

      只要是 automation 能帶來 high ROI 的，大概都被 automated 了

      security, scalability, i18n, l10n, UI test 方面
      除了 security, scalability 有 tool-assisted testing
      其他部分事實上用人來測試比較有效

      SDET 有花時間對整個 test execution stack 的改善
      讓 SDE 也能隨時跑任何 automated test case

      SDE 也花時間 refactor product code 使得 test case 有更好的測試方法

      這樣造成的結果，就是完善的 regression detection
      可以讓 (大部分的) SDE 全力往前衝而無後顧之憂

結論

* 在品質上不能讓步，所以在時程與成本這兩邊得要有那個膽識作長遠的投資

* 如果想要好的 SDET 支援，那就得花錢請有能力的人來作 SDET

* 想要好的 engineering system & practice ，那就得實質獎勵並支持
  那些願意花時間精神去改善 engineering system & practice 的員工

* 多積德，衝人品 XD

  本文講述的這個 product unit team 就是作微軟 ALM solution 旗艦產品
  Team Foundation Server (TFS) 的 team

  天天 dogfood 他們自己的 TFS 來作 ALM, 有用不順手的地方就修正
  用得順手的地方就 refactor 後拿出來賣, 聽了顧客 feedback 後再修正

  一般來說很少有機會作“能 bootstrap + dogfood 軟體本身的軟體”這樣的工作
  所以要多積德，衝人品…

註1: “微軟”是一個很大的集合體，這裡指的是 server & tools business 下
     developer division 下某個約 200 人的 product unit team

     windows / office / xbox / bing 那邊是怎麼作我不知道

     這篇是挑著一些重點講，雖然會偏頗些
     但實在也沒那個時間從頭到尾談一遍 orz

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 98.26.14.35

一些補述…

Q: 常常 product code 一動， test code 就要大改，怎麼辦?
A: 在本文這個例子裡，解決方式是

   * 聘請有能力的人來作 SDET, 所以 SDET 有能力去 refactor test code
     使用適量的 abstraction 使得 test code 與 product code 的連接點
     不會牽一髮而動全身
   * 讓 SDE 知道 SDET 是像後勤部隊一樣的友軍
     獎勵兩邊合作讓 product code interface 更乾淨, 穩定

Q: 為什麼不 100% 專注在於把 product code 寫好?
A: 列舉兩個理由

   * 一個 SDE 再強，總有一天他會贏樂透幾百萬美金去退休
     與其把重點放在單個 SDE 強者上，
     一個 reliable, performant, independent, isolated, transparent 的
     engineering systerm & process 比較有價值

   * SDE 本身還是會作 code review + unit test
     配合 SDET 從不同的角度監測品質, 那還不飛上天?

Q: 花錢請能當 SDE 戰力的人來作 SDET，有沒搞錯?
A: 如果你想要一個好用的 engineering system & process
   你就得花錢請有能力建立+運作
   engineering system & process 的人來為你工作...

Q: 這樣子的安排不會讓 SDE 鬆懈下來，隨便亂寫嗎?
A: 鬆懈多少一定會有，但如果老是寫出一些亂七八糟的東西，
   出那種“應注意而未注意”的包, 該 SDE 自然會被釘到牆上去

Q: 結果 test case 到底是有沒有用?
A: ledia 與 NDark 那兩篇 #1FmZXhcL #1FmZ-6x- 解釋過了: “看情形”
   如果你的團隊裡沒人能回答這問題
   花錢去請 consultant 回來，買他的時間幫你找答案。

Q: 我們小公司沒那個資本，句點。
A: 這裡是一張端士銀行的本票，價值三千萬美金…

Q: 我們小公司沒那個資本，怎麼辦?
A: 投資跟債務都是利滾利，
   找出 high ROI + low initial cost 的部分一點一點作吧。

Q: 微軟品質就是爛，句點。
A: http://www.microsoft.com/investor/EarningsAndFinancials/Earnings/PressReleaseAndWebcast/FY12/Q3/default.aspx

 REDMOND, Wash. — Apr. 19, 2012 — Microsoft Corp. today announced
 quarterly revenue of $17.41 billion for the quarter ended Mar. 31, 2012,
 a 6% increase from the prior year period. Operating income was $6.37 billion,
 up 12% from the prior year period.

   哭哭哦? :D

Q: 作到文中所述那樣子，就 GG 破關了嗎?
A: 非也, 舉兩個例子

   以 CI+P1 test 為例，跑一輪 1000 多個 test 要 8hr, 太慢了
   接下來是要讓 test execution 也能 scale out

   另外，還有許多 static / compile time / runtime 的 test technique,
   都可以想辦法在現有的自動化系統加進去來試試看有沒有實質上的效益
※ 編輯: AmosYang        來自: 98.26.14.35          (05/29 06:01)
※ 編輯: AmosYang        來自: 98.26.14.35          (05/29 06:17)
推 art1:超專業 o.o
推 zanyking:強～
補兩個在 derekhsu #1FmwBE2i 這篇看到的重點

Q: 如何讓 automated test 保持穩定?
A: 這是 SDET 的責任
   1. 讓 test execution (從 setup 到 analysis) 變得很簡單
   2. 執行這些 automated test as often as possible
   3. 把 #2 所找到的 test defect & flakiness 視作 product bug
      a. 迅速、確實地修正這些 test bug
      b. 找出方法來避免、減少 test regression

Q: 如何讓 automated GUI test 保持 high ROI?
A: You tell me. XD

   這得從個別案例的方式來討論了，很難給一個通用的答案
※ 編輯: AmosYang        來自: 98.26.14.35          (05/29 12:48)
推 bobju:搞測試的能算到ROI去,這非決策高層哪能夠?
是的，該 product unit team 老大 PUM (product unit manager) 手下
三巨頭 manager 分別管 PM, SDE, SDET

SDET 整支後勤部隊拿的待遇, 在決策過程中的分量，
是與 PM 及 SDE 平起平坐的; 相對的，SDET 要負的責任也一樣重
※ 編輯: AmosYang        來自: 98.26.14.35          (05/29 13:36)

重新申明一點: 這個 team 可以這樣玩成這樣算是一個特例

別的 team 要導入 ALM solution and/or practice, 都要背上投資的風險
這個 team 要對 ALM solution / practice 作實驗則是“產品研發”

* 覺得 Visual SourceSafe 太爛
  -> 開發 TFS 自己的 version control solution
* 覺得 TFS version control 無法承受微軟整個 developer division 的用量
  實在太爛 -> 將 TFS version control 提昇到 enterprise 等級
* 覺得 Product Studio 太爛
  -> 開發 TFS 自己的 work item / issue tracking 系統
* 覺得市面上 version control 與 issue tracking 之間 out-of-box 整合度太差
  -> 讓 TFS version control 與 issue tracking 有 out-of-box integration
* 覺得一天到晚老是 build break ，實在太爛
  -> 開發 gated check-in
* 覺得從 CI build 完成還要手動去跑 automated tests, 實在太爛
  -> 開發 integrated build testing
* 覺得傳統 issue tracking 介面 (像 Excel 一樣的列表) 實在太爛
  -> 開發 web-UI based task board (像 post-it note 的介面)
* 覺得 TFS 2005/2008 一定要配 MS SQL enterprise，實在太爛
  -> 在 TFS 2010 支援 SQL Express, 適合 home office / small teams 使用

  ... etc ... 不及列舉

在這樣的環境下，把 SDET 視為正規的後勤部隊 (而非外包的傭兵) 有許多好處,
除了能有效地改善 engineering system & process
也增加了各種 ALM solution 的實驗使用者, 更能第一手體驗到顧客的 pain points

易言之，要複制這個 team 的經驗並不是件很簡單的事
不是把“搞測試的”一夜之間變成一等公民，品質考試就會100分

這個 team 從 2002 開始，歷經了 TFS 2005 / 2008 / 2010 三個 major release
到現在正在作的第四個 major release 及線上版的 tfspreview.com
才有這樣的成績; 最後還是得看決策管理階層對品質時程成本的取捨
※ 編輯: AmosYang        來自: 98.26.14.35          (05/29 14:23)
推 bobju:人家測試是正規部隊,我們則是小7工讀生..(誤
推 yoco315:難得看到涵蓋範圍全面的中肯好文