Skip to main content

Q&A for QA

Question #01​

問題：

對於「RD 產出的 code 不測試, 就直接丟給 QA」這個現象的看法與建議？

Answer:

這我分兩個面向來看：

  1. RD 沒時間寫
  2. RD 不想寫

管理問題​

第一點，這應該不是 #能力 或 #意願 問題，而是 #專案管理 或 #團隊運作 造成 #時間 不夠充裕的問題。

不管跑啥方式 (看板 / Scrum)，RD 可以透過 Retro 去反應這樣的狀況，然後讓 Scrum Master or PO / TL 去協調，不管怎樣，要把時間喬出來做。這種投資是很值得，產出的品質會是更穩定可靠的。我相信只要專業度夠的 RD，都會知道要做好 UT 的 Sense，但是「做」需要時間。

時間這個因素，會牽涉到完成的完整度問題。工程師大多期許自己做到 #完美 (Perfect)，而時間的限制，需要工程師去思考 #完成 (Complete) 距離 #完美 有多遠。這也是了解工程師對於 取捨、Tradeoff 的能力，通常在拆工作項目時，可以看得出來。

意願​

如果是第二點，屬於 #意願，乃至於 #能力 問題，可以說是「人」的問題，然後就是影響整個團隊。

意願問題，應該是直屬主管或者現場的 Tech Lead 處理，因為 Code Review 應該就會看到 Unit Test 有沒有寫？如果 PR 沒寫 UT 就讓他過，那看點 Approve 的人就要負責。有些團隊因為人力佈局的關係，可能是成員之間相互 Review，而不是 TL，那就要往上一層去推，像是 PO / TL，請他們對團隊做這樣的要求。如果是到主管那邊的操作就是直接當作 KPI 去執行。

能力問題則由 TL 以及成員之間相互砥礪、相互學習，只要願意學，我相信都不會做得太差。TL 或團隊成員沒時間，那可以自己要求去外面上課，調整自己的不足。實務上遇到更多的是，有些 UT 不好寫，需要調整設計配合才可以，這種案例往往需要 TL 介入一起討論。

這樣在推的過程，一定會遇到 #時間 不夠的問題，回到第一點，由 PO / TL 處理 or SM 處理；

摘要​

執行任務的過程的三大要素：#方向、#資源、#時間 缺一不可。而「人」的前提則是意願與能力。

Question #02​

問題：

身為一個負責開發業務需求的 RD，Code 寫好後，測試要做到怎樣的狀況，才能交給 QA / Tester？

Answer:

我自己以前 as a developer 的時候，作法如下：

  1. 完成 DCUT (Design, Coding, and Unit Test)
  2. 確認 Build Pass
  3. 拿 Build 好的 Artifact 在自己的工作環境安裝，確認 Config / DB 沒問題，跑得起來.
  4. 跑過 Happy Paths，確認需求上描述的功能已經都滿足。
  5. 沒問題了，請 QA 測其他的 Test Cases

這五個步驟，不管是 Web / Desktop / Mobile 我都是這樣走。

相關討論與回答：

結論​

任務都有資源、時間、風險、成本 ... 等各種因素，
在時間有限、資源有限的時候，
考驗的是團隊協作的共識，
有時候：

完成 (#Complete) 比 完美 (#Perfect) 更重要。

原始資料​