前情提要
約耳測試是我早期在評量一間公司的軟體團隊成熟程度的指標，
非常簡單好用，像極了軟體業的艾卜佳評分表,
可以參考我之前的文章
最近要換工作了，再看看約耳測試的評量表，有了一些想法，特別記錄下來
我的看法
比較表
| Joel Tests | 2022 Marsen’s Explanation | |
|---|---|---|
| 1 | 你有使用原始碼控制系統嗎? | 你有使用 Git 嗎? |
| 2 | 你能用一個步驟建出所有結果嗎? | 新人需要多少步驟才能建立好開發環境 ? |
| 3 | 你有沒有每天都重新編譯建立(daily builds)嗎? | 你有高品質自動化整合/迴歸測試嗎? |
| 4 | 你有沒有問題追蹤資料庫(bug database)? | 你有 Issue Tracking System 嗎? |
| 5 | 你會先把問題都修好之後才寫新的程式嗎? | 你有管理你的技術債嗎? |
| 6 | 你有一份最新的時程表嗎? | Scrum: 你知道 Sprint 的目標嗎? Other:你最重要的事是什麼? |
| 7 | 你有規格嗎? | 你有規格/POC/mockup 嗎? |
| 8 | 程式人員有沒有安靜的工作環境? | 你一天會有多少會議?常常被打斷嗎? |
| 9 | 你有沒有用市面上最好的工具? | Cloud/IDE/所有開發人員的開發體驗是一致的嗎? |
| 10 | 你有沒有測試人員? | 你有 QA 團隊嗎? |
| 11 | 有沒有在面試時要求面試對象寫程式? | 有沒有在面試時要求面試對象寫程式? |
| 12 | 有沒有做走廊使用性(hallway usability)測試? | 你有 UI/UX 團隊嗎? |
你有使用原始碼控制系統嗎? 你有使用 Git 嗎 ?
這題我覺得比較沒有爭議，分散式版控與集中式版控之爭已經是十年前的討論，
Git 可以說是唯一選擇，雖然曾有一些說法試著說明 Mercurial 比 Git 更好，
但是市場証明了一切。
初學者學習起來資源多、門檻低、工具鏈完整，進階者不能不會 Git。
不論是開發流程、測試、需求管理 Git 的應用應該被包入日常作業之中。
有用 Git 是基本的基本，困難的是如何整合在你整個日常作業之中。
但原本的題目是「你有使用原始碼控制系統嗎?」 所以我想只你有在用 Git 就當作合格吧。
你能用一個步驟建出所有結果嗎? 新人需要多少步驟才能建立好開發環境 ?
這題有點難，我本來想用「你怎麼實作 CI/CD ?」，
但即使到了今天，這也是個大哉問，一鑑還原可以當作一個目標，
在實務上，通常可以作到 3 大步驟就完成開發環境建置我覺得是最理想的。
- 取得源碼(git clone)
- 取得/設定授權(internal auth/password/credential)
- Build & Run
你有沒有每天都重新編譯建立(daily builds)嗎? 你有高品質的自動化整合/迴歸測試嗎?
這題有兩個面向，一個是測試的頻率，一個是測試的品質，
在工具發達的今日，高頻測試不是難事，你可以每天建置一次，也可以每次部署都建置一次。
重點反而在於，你的整合與測試是不是符合品質的，在實務上看到太多為測試而測試的案例。
或是追求特定指標(每日建置次數/測試覆蓋率等…)而無法真正達到為品質把關。
不過回到這題，你有高品質的自動化整合/迴歸測試嗎 ?
有沒有很好量化，高不高品質就難說了，也許問題可以改成
「你有自動化整合/迴歸測試嗎?如果有的話，請舉例說明曾被測試救了一次的經驗(欄截到的錯誤版本)?」
舉不出例子就是種壞味道，很有可能他的自動化整合/迴歸測試是自我滿足或是吹牛用的工具，
而不是真正對產品有用保護。
你有沒有問題追蹤資料庫(bug database)? 你有 Issue Tracking System 嗎?
這題我覺得也是基本題，如果有的話可以追問
- 需求的分級
- 一般需求與緊急需求怎麼處理 ?
- BUG 與 Defect 怎麼處理 ?
如果沒有 Issue Tracking System 的公司一定雷，自已好自為之。
你會先把問題都修好之後才寫新的程式嗎? 你有管理你的技術債嗎?
這題與上一題有所關連，但是上一與之相關的人員比較像是 PM/PO/管理者的角色，
而這題更多是 RD 需要負起的責任。
實務上為了快速滿足需求，欠技術債是難免的，與其不欠債，不如好好管理債務，
那 Issue Tracking System 就會是一個很好用的工具。
而實際台灣的業界，我蠻常看到 RD 是欠債不理的，用一些神乎其技完成了某功能，
然後離職無人能接手(或是難以接手)，再去各大社群或是大會演講，
雖然技術很領先，但這樣的人實在讓人難以尊敬(不過看起來他們是過蠻爽的啦)
你有一份最新的時程表嗎? Scrum: 你知道 Sprint 的目標嗎? Other:你最重要的事是什麼?
這裡特別提到了 Scrum(請參照 Scrum Guide，其它捉文解字的、守破離的、殞石開發的不算 Scrum )
因為在 Scrum 的 Sprint 設計是有目標導向的，
而不是 Scrum 的話，你知道你最重要的事情是什麼嗎 ?
至少要說出前 3 項，與短中長程的目標，人無遠慮必有近憂，
這個問題適用於開發主管與產品主管，可以了解這兩個面向公司的發展與未來性。
你有規格嗎? 你有規格/POC/mockup 嗎 ?
這題其實不用改，即使敏捷宣言說Individuals and interactions over processes and tools，
但是這些文件實務上是能帶來很多好處的，在各行各業都有類似的手冊、文件來幫助溝通，
很多時候你也可以錄影/錄音來加速增加溝通的效率，不要太過極端就好，
如果是 010 來評分的話，我建議至少要有 68 成規格應被置成文件(不論影音文字)
程式人員有沒有安靜的工作環境? 你一天會有多少會議?常常被打斷嗎?
例行性會議有多少 ? 非例行性會議(頻率)有多少 ?
多久會 1-1 ? 這些問題很看管理者的風格，但是又很打擾開發者，
另外如果面試爽約、逾時、讓你乾等等…可以視作一種壞味道，不仿可以切入追問。
你有沒有用市面上最好的工具? Cloud/IDE/所有開發人員的開發體驗是一致的嗎?
現在的工具實在太多，還有各種外掛，所以要讓開發人員的開發體驗一致是相當困難的，
建議在建立開發人員(可以依團隊劃分)的環境文件之中，應該要有一份共用且最新的相關設定的檔。
~~你有沒有測試人員?~~~ 你有 QA 團隊嗎?
測試已經是一門水很深的領域了，如果沒有一個團隊在負責測試，或是沒有自動化測試，
要小心這是個壞味道，或許你可以把問題變成「測試團隊怎麼驗收功能?」
有沒有在面試時要求面試對象寫程式 ?
不得不說我也很不喜歡面試時寫程式，最主要是常常面試的題目難如登月，
進到公司後，卻在作九九乘法表般的開發。
網路上甚至都有「面試造火箭，入職擰螺絲」一說了。
樂觀的說，如果你不懂得造火箭，那你的螺絲很難擰得正確，
悲觀的說，這些資訊主管，正缺乏一種正確評量人的方法，所以只能用這種方法進行篩選，
而且這方法還算行得通。
反之，我反而很想在面試的時候，有機會可以跟面試管或是未來的同事 pair programming。
有沒有做走廊使用性(hallway usability)測試? 你有 UI/UX 團隊嗎?
走廊使用性測試我並不熟，我的理解是盲測使用者怎麼使用你的產品?
目前的業界通常有專門的 UI/UX 團隊在處理，不過要怎麼預測使用者行為仍然是很難的
最後看看這篇經點的笑話
一個測試工程師走進一家酒吧，要了一杯啤酒
一個測試工程師走進一家酒吧，要了一杯咖啡
一個測試工程師走進一家酒吧，要了 999999999 杯啤酒
一個測試工程師走進一家酒吧，要了 0 杯啤酒
一個測試工程師走進一家酒吧，要了-1 杯啤酒，
一個測試工程師走進一家酒吧，要了 0.7 杯啤酒
一個測試工程師走進一家酒吧，要了-10000 杯啤酒
一個測試工程師走進一家酒吧，要了一杯蜥蜴
一個測試工程師走進一家酒吧，要了一份 Qer@24dg!&*(@
一個測試工程師走進一家酒吧，什麽也沒要
一個測試工程師走進一家酒吧，又走出去又從窗戶進來又從後門出去再從下水道鑽進來
一個測試工程師走進一家酒吧，又走出去又進來又出去又進來又出去，最後在外面把老闆打了一頓
一個測試工程師走進一家酒吧，要了一杯燙燙燙的錕斤拷
一個測試工程師走進一家酒吧，要了 NaN 杯 Null
一個測試工程師沖進一家酒吧，要了 500 杯啤酒咖啡洗腳水野貓狼牙棒奶茶
一個測試工程師把酒吧拆了
一個測試工程師化妝成老闆走進一家酒吧，要了 500 杯啤酒並且不付錢
一萬個測試工程師在酒吧門外呼嘯而過酒保從容應對
測試工程師很滿意
測試工程師們滿意地離開了酒吧
一名顧客點了一份炒飯
酒吧陷入火海
murmur 一下這些充滿美學卻不能被叫美工的人，說得自已好像賈伯斯，
大多是我覺得或是我的經驗，很少在依賴數據判斷，或是與工程團隊互動，
去建立回饋機制或 A/B Testing。
參考
(fin)