很多人以為，測試人員「只靠測試」，來測出 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 年下半年，幫助大家開地圖，帶著大家一起砍怪升級練技能。
曳光彈式開發 在 程序员修炼之道系列| 使用曳光弹找到目标 - 禅道 的相關結果
使用曳光弹找到目标，我们可以理解为：MVP + 即时的反馈+ 快速迭代。 ... 我们在做产品的时候，可以用采用曳光弹式开发。避免了从复杂繁重的文档和大 ... ... <看更多>