- Black box testing technique
- 等價劃分（equivalence partitioning）
- 邊界值分析（boundary value analysis）
- 狀態機測試（state-based testing）
- 劇本測試 （scenario-based testing）
- 依據Use Case或是story來測試功能是否正常
- 金句
- 首先，你沒有規則
- 接著，你學到一個規則並將它套用在所有地方
- 然後，你學會很多規則，這些規則經常彼此衝突，一不小心便在不對的情境中套用不合適的規則
- 慢慢地，時間讓你知道套用規則之間的取捨因素，經過刻意觀察與思考你具備感知force的能力
- 最後，你從情境（context）中直接發現答案，你已不需思考規則便可做出決策
- 估算story（需求）要採用story point這種沒有單位的「相對大小」估算方法，而估算task（工作）卻是用小時為單位？
- 用「相對大小」來估算唔同需求，因為人類對於估算相對數據比估算絕對數據來的擅長
- 用實際時間估計估算到達「目的地」所需時間
- 專業分工係「局部最佳化」
- 工作調度彈性 -> 減低團隊合作 & 工作怠倦 -> 長遠減低生產力
- 「多才多藝」不是說每個人都一樣，沒有專業可言
- 而是團隊成員在某項（或某幾項）技能具備熟稔的專業能力之後，也不要排斥接觸新的技能，把握擴展自己專業領域的機會
- Pair debugging steps
- Driver
- 說明錯誤訊息與錯誤現況
- 解釋可能出錯的程式邏輯
- 系統架構（模組與模組之間的互動關係）或是一起看一下某段程式碼的內容。
- 如有測試案例，跑一下
- 請對方猜測可能發生錯誤的原因
- Navigator
- 問問題：
- 這個API這樣子使用對嗎？它的傳回值是什麼意思？如果是null會怎樣？
- 這個物件是由誰來負責初始化的？會不會根本就初始化失敗但是卻沒人發現？
- 如果網路斷線，這段程式可以立刻知道嗎？還是會卡在這個method上面？
- 如果心中有任何疑惑，千萬不要用「猜的」，或是「抱持著在公堂之上大膽假設一下應該不犯法」的這種想法
- Don’t Assume It * Prove It
- 咩時候適合用Pair programming
- 重要新功能的 coding 工作
- 如果系統的架構與設計已經有了大致的想法
- 否則最好討論一下design
- Big refactoring
- 帶新人
- 知識傳遞
- Debug
- 寫測試案例
- Big Refactoring
- 唔洗100%行pair programming
- 「軟體架構逐步成長」作法
- 要同時採取 top-down 同 bottom-up 嘅設計
- top-down
- 分析架構是否可以滿足quality attribute requirements
- bottom-up
- 分析實作面以及環境相關的限制
- 有哪些現成的軟體元件、框架、或技術可以使用，取捨的依據是什麼
- 當專案開始時，要能夠快速地建立 prototype
- 驗證軟體架構的概念
- 然後依據使用者的需求優先順序，按步就班實作與修正架構
- 當新需求出現，或是團隊成員對於問題領域有更深入的了解之後，調整現有架構，並且重構設計
- 隨著專案演進，持續地實驗與評估軟體架構是否合用
- 要達到讓軟體架構變軟，從高到低有以下幾個層次
- 了解architecture pattern
- 「整體先於部分」
- 在開發初期，雖然需求尚未清楚的釐清，實作也還沒開始，但是軟體架構類型還是可以事先挑選。
- 例如，MVC、Client-Server、Plug-in、Layered等等
- 至於架構中的「肉」，可以隨著開發而逐漸長出
- 例如應用程式需要用到persistence的需求，可以先用一個簡單的O-R mapping的方式來處理，後端可能只用簡單可以支援儲存（key，value）的資料庫
- 等到發現效能無法滿足時，再來考慮要如何提升效能。
- 如果效能不是一個問題，這樣的架構也就不需要修改
- 雖然說「Do not pre-architecture too mush」，但是像這種大範圍架構還是需要先選擇與決定會比較好一點
- 了解design pattern
- architecture pattern只是一個殼，真正要把肉長出來，還是需要範圍比較小的design pattern
- 有人稱design pattern為micro-architecture（微架構）
- 對於一些規模比較小的軟體，甚至只要直接套用design pattern便可解決設計上的問題
- 往上可以串接軟體架構，往下則是累積了許多優良的物件導向設計經驗，所以算是一個很好的學習設計與架構入門點。
- 了解物件導向設計觀念
- 有了正確的物件導向設計觀念，先可以明白 architecture 同 design pattern 點解咁樣設計
- 至少熟悉一種程式語言
- 處理 Story 做不完嘅兩個做法
- 把 story 移到下個 sprint 繼續做
- 把 story 範圍切小一點，在這個 story 中 demo 已經完成的部份。
- 好像只是在玩『文字遊戲』，但是這其中的差別其實是很重大
- 每個 sprint 結束都完成一個潛在可發布的軟體
- 如果有人宣稱 story 做完了但是 sprint 結束之後卻『無法交貨』，那麼這種說法就是很有問題的
- 如何處理在 sprint 中會不會無法完成測試
- Programmer test
- QA test
- 冇 QA team
- 可以由 product owner 兼做驗收測試，一完成其個 story，就馬上可以測試
- 有 QA team，兩種做法
- QA team 測試 developers 這個 sprint 所完成的 stories
- Dev implement 嘅時候， QA 就開始設計 test cases
- 需要 QA 同 Dev 協調得好
- 時間比較緊張
- QA team 測試 developers 上一個 sprint 所完成的 stories
- 時間感覺上比較充裕
- 但如果 Dev 仲改緊個 feature，可能下個 sprint 又要重測
- 兩個 QA 重點
- QA 要有能力設計測試案測
- 唔係只識跟 Dev 指示去 test，做「人肉 Test Robot」
- QA 要參與 development
- 可以 automate 嘅 test 就盡量 automate