在 Odd-e 的 Nerd Talk 中,
我分享了之前在測試管理方面的一些經驗
我有在 Facebook 問大家對哪些有興趣
大家填了一下 survey, 結果如下
因為已經有錄影檔:
https://www.youtube.com/watch?v=Dwpa-g7P2Q0
所以這邊只先簡單紀錄了幾個問題的分享的內容
(1) 沒時間怎麼辦
當開發遇到做不完你會怎麼辦, 不外乎是加班, 加人, 延長時間, 砍功能或是分批交付
前面三個方法, 用了不一定能做完
通常是後面兩者比較有用
可是為什麼老闆或是客戶要答應你呢
大多是因為剩下的不重要, 他們才有意願答應你
如果剩下的都是重要是的需求, 那你就倒大楣了
同理, 測試也是如此. 你需要將要測試的東西排出優先順序
把重要的東西先測, 剩下不重要的才有機會跟人家談簿冊或是分批測
不過很重要的是, 是對誰重要
需知道工程師的重要, 可能跟客戶或是老闆的重要是差很多的
(2) 沒有人怎麼辦
首先要去了解長官為什麼不加人
是專案不重要, 還是測試不重要, 或是其他原因
有時候是他不知道如何平衡時程和測試
這時候你就需要幫他想辦法解決它所擔心的事情
如果以前有因為品質沒把關好出大包
這時候要趁機以戰逼和, 跟他要求有些測試要多做，
或是某些角色(通常是 RD)要幫忙做
在時程的壓力下當然無法做很多
但是重點要 > 0 而不是 = 0, 要比之前做的再往前跨一小步
另外, 團隊除了 QA 外是否有其他人
為什麼他們不能做
在事情多的狀況下
應該是只有事情別, 而沒有角色別
要全民皆兵, 這樣比較有機會可以做得多一點
(3) 需求不清楚怎麼辦
基本上遇到這個問題, 就會開始指責大會
就會說 PO 沒說清楚, 然後 RD 說了又不懂
通常我會要求幾件事
a. 提解法要從自己要做什麼開始, 不要要求別人要做什麼
b. 換位思考, 對方為什麼會這樣想, 如果你是他, 你是否能提出更好的作法
之前對於需求不清楚, 我會利用
在測試左移的階段, 多個 review 關卡來減緩這個問題
利用 review UI spec, review 開發架構, review test case, code review
看起來好像是在看每個角色做得事情是否正確
但是在這他們的東西時間, 可能有 1/3 or 1/2 時間再確認要做的需求是什麼
藉由大家一起檢視, 來學習和達成對需求的共識
(4) 長官不重視怎麼辦
這一題和"沒有人怎麼辦很像"
基本上還是要去了解長官在意的點在哪裡
另外就是稀缺效應
大多數人就是把精力分在又急又重要的事情上面
沒有抽空來做不急但是重要的事
導致你總是品質一直不好, 沒空做自動化
另外有時候是長官不知道這件事情這麼嚴重
原來品質這麼不好, 或是這個不解影響這麼大
你必須要從商業角度說明給他聽
並且要能提出解法, 最好是 2-3個
讓他有選擇, 讓他知道優缺點
一方面讓他有選擇, 也就是讓他有參與感
一方面也讓他知道你思考的點在哪邊
最後是他決定要用什麼, 自然也比較會 buy-in
(5) RD/QA 比例怎樣最好
基本上這是錯誤的問題
沒有標準答案怎樣比例最好
要看以下因素去考量
a. 專案複雜度:
如果專案很單純, 其實可以就讓 RD 去測就好, 不需要 QA
b. 測試的工作誰在做
如果 RD 都不做 unit test, code review 等等確認品質的事情, 自然就會需要很多 QA
c. 對品質的要求
有些時候 1.0 的產品, 根本不需要先要求品質, 而是要先確認客戶是否要這個產品
d. 團隊的能力如何
如果開發不會 TDD, 或是 QA 不寫會程式, 自然就會因這狀況決定如何分配工作
e. 開發流程
如果流程中有 CI 並且持續頻繁進行, 或許也可以不需要太多 QA
(6) 如何提升軟體測試能力
了解客戶
多讀 bug 報告
多讀 程式碼
為找到 bug 感到驕傲
參與功能的設計
了解你要測試的功能
和別人合作測試你負責的功能
提升開發的能力
參與相關社群
學習你測試的軟體系統
和 RD, PM 培養良好關係
尋找導師和益友
持續自省
管理自己的時間
適當地自動化你的工作
參與 bug 檢視
持續學習新技能
(7) 如何知道 QA 績效好
a. 定量
找到的 bug 數目
開立的 test case 數目
這些高非絕對這個 QA 就一定績效好, 但是正相關
b. 定性
design/spec review meeting: 提出要注意或是遺漏的地方
test case review meeting: 考慮周延
bug report: 仔細並且有很多建議
RD 的回饋: RD 如果會說這個 QA 很值得信賴
其他QA 的回饋: 說這個QA 會提出很多建議, 或是提供很多工具
文章標籤
全站熱搜
留言列表
