Search
我在 2021 年的其中一個新嘗試：跟同行的專業講師 相互交流求進步。
心裡很感謝 六角學院院長 洧杰 在今年初先參加了 極速開發 的培訓，然後還創下一個壯舉：「在課前四個月，就先把上課的內容範圍摸了一遍，而且動手練習。」
（搞得後面報名的學員每個人都很早就很擔心，是不是要提前練習很多東西，才不會在上課跟不上 XD）
一般學生學完能用在實務上就已經很了不起了，學完用在實務上，再演變成自己的內容，去擴大影響力，這樣的能力就更少了。
做到這樣的成果，還願意提及與感謝自己的學習來源，讓我可以一起沾沾光，一起感到榮耀，這就不只是能力卓越，而是還包含了人格特質值得相交。
六角學院的學習系統很有趣，也很用心，對於許多想轉職、入行當軟體工程師或是前端工程師是個很不錯的選擇。
當然，如果是已經工作幾年，想要更進階加強各種基本功與設計、軟體工程能力，就可以接著參加我的各門培訓啦！
期待 洧杰 後續在 商業思維學院 的主題講座分享，也期待今年後面梯次的「針對遺留代碼加入單元測試的藝術」以及「TDD與持續重構」兩門課的交流。
上次引用到 Joey Chen 對 測試人員 目前的看法(在下面), 今天繼續聊聊 XD
”測試人員應該需要具備自動化的能力，但撰寫自動化測試程式不應該是他們投入最多時間與心力的著力點。
他們應該去自動化那些過去很花他們時間的 routine 工作（不只是程式，可能還有文件），讓他們能擁有更多的時間聚焦在產品，對產品品質能有發散的觀點，捕捉風險項目，實例化情境，幫助開發人員、甚至需求人員把需求的輪廓跟邊界切出來。
這是測試人員把特質發揮到極致的價值“
去年在 Agile Summit 2019 中有分享 agile testing strategy, 和 Joey 上面提的想法是類似的, 個人覺得包含以下重點:
https://www.slideshare.net/ssusere62027/agile-summit-taipei-2019-agile-testing-strategy
A. 測試左移
測試不應該是一個階段, 不該再開發完後才做, 要在前面就融入開發流程, 也就是 test left. 像是需求檢視, 參與設計討論, pair testing, static testing 等等都是.
B. 源頭錯, 後面自動化再好還是錯
很多團隊認為 QA 後來在進來測就好, 前面討論需求不用進來, 進來了也聽不懂. 事實上, 軟體開發最怕的是做錯需求, 如果一開始 QA 可以幫忙把需求弄的完整, 把一些錯誤處理狀況討論好, 讓 RD 一開始就有考慮到, 就有處理到, 後面就不會說改這個要動搖國本, 或者是之後改 bug 再來修修改改, 這樣的程式架構才會比較漂亮. 當然啦, QA 也是要培養出能跟 PM , RD 談需求和設計的能力.
C. 工具很重要
工具很重要這件事, 對 RD or QA 來說都是很重要的. 我很少看到資深厲害的工程師, 手頭上沒有一堆軍火庫. 如果有工具可以幫你產生測試資料, 模擬某些測試環境, 或者是當 fake server 等等, 都會讓日後的生活好過很多.
D. 測試自動化的重心.
就如之前 LInkedIn 那篇, 自動化的主力應該是放在高價值, 低維護成本的 happy path, 讓主要價值都有被保護, 並且也不會花工程師太多時間去維護測試程式, 須知測試程式的維護往往是最大的夢魘, 通常占自動化成本 80% 以上. 如果能做到上述原則, QA 就可以利用 exploratory testing, 去探索更多未知領域, 而不是在撿那些立馬就錯的爛 bug.
很多人以為，測試人員「只靠測試」，來測出 bug，但事實上他們負責的是「品質」，他們的價值不只是測試本身，更多的是：
☆ 找出哪一些東西需要測試
☆ 說明哪一些東西不測試可能會有什麼樣的風險
☆ 哪一些東西雖然在開發人員的定義不是 bug，卻影響到使用者用起來的感受與品質
☆ 甚至他們需要在短時間內快速探索、學習「新產品」或「新領域」的能力，了解這樣的產品提供了怎樣的功能，是為了解決使用者的什麼問題。
這是我覺得「真正專業的測試/品質工程師」所具備的專業價值與能力，而且這很吃天賦、個人特質，不是每個人都適合或做好的。
很多專業的 QA 才是真正的 domain expert，他們的天性是發散、建立關聯、探索、聚焦、學習。
然而，如果把一般功能的驗證，產品開發的邏輯 bug，也都交給 QA 來一概承擔，那我覺得這產品的極限可能是「沒有 bug」，但「品質」不一定是高水準的，因為 QA 的能力被用在低效的產出上。
▍開發人員怎麼跟測試人員相輔相成
開發上大部分的 bug，都是因為「寫的跟想的不一樣」，想的沒 bug，寫出來卻有 bug。
※ QA 是幫忙解決：「想錯」的 bug。
這問題適合用「#單元測試」來解決，夠多扎實、涵蓋程度夠廣的單元測試，可以避免這類「低級錯誤」。
當正式環境產品出錯的時候，透過單元測試可以快速定位出問題的位置與原因。
※ 如何在賺錢的 legacy code 上，優雅地加入【單元測試】，請參考：https://dotblogs.com.tw/…/201905-unit-testing-effectively-w…
另一種 bug 是每個人寫的都沒問題，但串起來的部份沒做好。這類就適合依靠「#驗收測試」來模擬，站在使用者的角度，用使用者的情境，自動化的去「走」這些情境，驗證功能、情境、資料是否如同預期。
該怎麼確認我們的「驗收測試」沒有想法上的問題，會不會我們覺得是對的，但跟需求單位想要的不一樣？
當然有可能，而且很常發生。這問題通常透過「#實例化需求」來避免。在實例化需求過程，有需求單位、有 BA、有 QA、有 Dev （當然，這只是指團隊有人可以 cover 該角色所具備的技能即可）
那有沒有可能， #實例化需求 仍然不夠？例如：開發團隊做出來的，既符合當初的驗收情境，也通過 QA 的品質要求，PO 也認為這是當初講的東西，但看完之後，PO 覺得當時想錯了，他有更好的想法，或是需要更好的想法呢？
當然有可能！而且這才是「正常」。在看不到實際的功能、使用的情境，只有空想、文字、圖片或雛型，事實上是很難出現「更好的想法」。
但一旦看到了產品功能，一旦試著使用，就更容易激發出更好的想法、更多改善的方式。
所以，Agile 的「#快速迭代交付產品增量」、「#MVP / #MMF」、ATDD/TDD 的「#可行走的骨架」、「#曳光彈式開發」，都是為了能用最小的付出，獲得最大的 outcome。（這個 outcome 不只是功能本身，也包含了發現我們的功能根本是無用的廢物，或是發生了不同的 event 而產出更棒的作法）
最後，有沒可能上面的理想狀況都做好了，但產品卻因為功能頻繁修改，而越來越慢、越來越肥、問題越來越多？
當然有可能！所以，從一開始的設計，就要 #即時重構，要重構前要有測試的保護，如果一樣都要寫測試，那 #TDD 會比候補測試來得更加「事半功倍」，用測試來描述情境、驅動開發、維持易用性，搭配重構來穩定設計、確保彈性、夯實品質，讓開發與維護的成本曲線是緩慢上升、斜率趨近於0的直線。
※ 想要用測試描述需求、探索需求、分析需求，並找到核心的情境，適當的開發順序，請參考【TDD與持續重構】：https://dotblogs.com.tw/…/201907-evolutionary-development-t…
※ 想要從軟體架構設計上達到「職責、關注點分離」，讓團隊能依循這樣的設計規範來達到「消除重複」，可以善用【DI與AOP】的設計，請參考：https://dotblogs.com.tw/…/201905-dependency-injection-and-a…
如果該具備的基礎建設都有，該了解的功能實踐基本也都能掌握，但你的產品開發的瓶頸，最後是卡在「時間不夠」、「時程太趕」，那其實問題有兩種。
第一種，需求沒照價值的優先順序排列，且不具備「捨棄」低價值功能的勇氣，想要的太多，需要的太少，當然快不起來。另外這一類問題常見的還有，無法把需求 end-to-end 的切細切小。
第二種，就是開發能量的不足。老話一句，加人是沒用的。在產品開發的領域，scale-up 遠比 scale-out 實際多了。三四個精英可以抵得上兩三個團的戰力。
如我最近最常講的一句話：「我認同沒有時間是個問題，那你做了什麼來改善這個問題呢？」
※ 很多人的開發方式、開發環境、開發工具，根本是原始人等級的，想要往【極速開發】的領域邁進，請參考：https://dotblogs.com.tw/…/2…/11/29/201905-extreme-developing
最後，有沒可能講了那麼多，都只有自己會，但團隊不買單、老闆不買單？
當然有可能，導入變革本來就是軟硬技能的綜合體，如何發揮影響力，如何幫助大家無感，如何找到對的 roadmap，如何讓大家嚐到甜頭，如何讓大家自己想要？
這是敏捷教練+技術教練的職能範圍。
※ 想要 train 出自己團隊的 internal coach? 請參考【工程實踐與流程規範導入實務】https://dotblogs.com.tw/…/engineering-practice-and-process-…
▍Road Map
上述雖然好像是打廣告，但我真心希望各位產品開發的朋友們想一想，整個產品開發事實上真的要具備很多專業的技能。
我在 2018 年、2019 年所開立的課程，就是希望把這條 road map 拉出來，幫助大家打通。
每一塊都是不可缺少的拼圖，一環扣一環，你能找到兩塊拼圖拼起來，就可以獲得 1+1 > 2 的綜效。
最後，還有幾門主題是這條 road map 上我正在準備的內容：
① 實例化需求
② 敏捷落地 (agile, scrum, lean, kanban, XP 揉在一起的綜合技)
③ Exception and Error handling
希望能在 2019 年下半年，幫助大家開地圖，帶著大家一起砍怪升級練技能。
因年後手動測試工程師(不寫程式)會離職，內部討論後決定來搭建更良好的測試流程 ... 單元測試，先找QA 特質好，且未來不排斥學著自動化自己平時工作的測試工程師（現在 ... ... <看更多>
什麼樣的人適合當 工程師 難怪你說我不像 工程師 ✨ 猜猜你的人格來對 ... MBTI 人格 特質測試 ！你是那1%嗎？ ... 軟體工程師 面試, 都考什麼資料結構嗎？ ... <看更多>
軟體測試 工程師 特質 在 Re: [問題] 測試工程師的未來? - 精華區Tech_Job - 批踢踢實業坊 的推薦與評價
我以前也是做跟你一樣的,QA是拼耐心的,想寫程式的話可以試看看自動化測試
這應該是QA比較有前景的一塊,
一般QA在公司是比較不被重視的,可是又很重要(出問題第一個就找QA)
比較適合機械式性格的人做(?)
職務你就不用想有什麼延伸了,QA也分很多種,跳到另一種就是全新的領域.
QA本身就是不重深度，比較重廣度的工作.
所以關於系統方面你是可以學到不少,可是當你學差不多了，你可能會覺得無聊反覆.
做QA真的要很有耐心,不然不要輕易嘗試...
※ 引述《denniscool (不願向命運低頭)》之銘言：
: 小弟剛進公司快兩個月了
: 被分配到的工作是做測試網路方面的工作
: 線在都在看些文件及測試範本
: 未來要對軟體工程師寫的程式做測試
: 因為測試工程師比較不太摸到程式
: 比較常摸到的是硬體測試環境(如Switch....)
: 雖然裡面的同事人都很好 也很願意教人
: 但畢竟工作內容不相同
: 我是想要學習到系統方面的東西
: 所以想要請問各位先進
: 如果是做測試工程師的話
: 學習東西之後可以轉到像哪種較有前景的公司或職務呢?
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.135.8.136
... <看更多>