約耳測試馬森版

前情提要

約耳測試是我早期在評量一間公司的軟體團隊成熟程度的指標,
非常簡單好用,像極了軟體業的艾卜佳評分表,
可以參考我之前的文章

最近要換工作了,再看看約耳測試的評量表,有了一些想法,特別記錄下來

我的看法

比較表

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 杯啤酒
一個測試工程師走進一家酒吧,要了一杯蜥蜴
一個測試工程師走進一家酒吧,要了一份 [email protected]!&*(@
一個測試工程師走進一家酒吧,什麽也沒要
一個測試工程師走進一家酒吧,又走出去又從窗戶進來又從後門出去再從下水道鑽進來
一個測試工程師走進一家酒吧,又走出去又進來又出去又進來又出去,最後在外面把老闆打了一頓
一個測試工程師走進一家酒吧,要了一杯燙燙燙的錕斤拷
一個測試工程師走進一家酒吧,要了 NaN 杯 Null
一個測試工程師沖進一家酒吧,要了 500 杯啤酒咖啡洗腳水野貓狼牙棒奶茶
一個測試工程師把酒吧拆了
一個測試工程師化妝成老闆走進一家酒吧,要了 500 杯啤酒並且不付錢
一萬個測試工程師在酒吧門外呼嘯而過

酒保從容應對

測試工程師很滿意

測試工程師們滿意地離開了酒吧

一名顧客點了一份炒飯

酒吧陷入火海

murmur 一下這些充滿美學卻不能被叫美工的人,說得自已好像賈伯斯,
大多是我覺得或是我的經驗,很少在依賴數據判斷,或是與工程團隊互動,
去建立回饋機制或 A/B Testing。

參考

(fin)

Please enable JavaScript to view the Gitalk. :D
Please enable JavaScript to view the LikeCoin. :P
Please enable JavaScript to view the LikeCoin. :P