Warning: 本篇部份為幻想文
最近公司在出release build. 幾乎是每日一build來的。
在以前的公司， daily build 的經驗非常之少，現在這個團隊真的了不起哩!
不過令我個人非常苦惱的事情是，這幾個build 測得可說是2266。甚至有很嚴重的情況是說：同事玩到的blocking defect，我還不知道那個功能在那邊................實在是很囧. 一開始其實不很明白為何會出這樣的狀況，很迷惑。但是後來和朋友討論的後，發現源頭是因為我對規格不是很了解的關係。目前的做法是，出build 的時候，我就來個反向工程，把介面上的異動想回規格再測它。那如果沒有留意到的小更動，自然也就不會測到。
仔細想想這樣會爆也合理(?) 如果是XP 裏的iteration plan 是要連qa 一起進去的，sa 一邊講規格，qa一邊想怎麼怎麼可以搞爆這個規格。(當然programmer 也會做大概的design + analysis) 更極端的例子是，有些團隊的qa也是programmer，她們隨團隊一起開發，並且在開發的過程中隨時提出邪惡的點子來惡整這個軟體。如此一來，高風險的功能早就在開發的中間就千錘百鍊了，也不用到出build 之後再來找qa 在另一個小房間測它。
這種做法的好處是很有效率。比方說我今天來寫個核心引擎是要來index 全文，要能撐得住terra byte 的文件量，在某種機器上的response time 回應必需在0.5 sec以內。那最好的方式就是在決定用那一種底層架構的時候，qa 就一起對開發中的半成品做一些極端的折磨。如此一來在開發之初就可以確知可行性為何，架構是否健康。不用等介面(html? webservice? interface?)都寫好了再找qa 進來，此時發現不行再來更動，所花的時間成本就高了。
那麼，理(幻)想中的qa 要有什麼功能呢?
(1)在訂規格的時候了解規格
(2)對軟體邪惡
(俗話說，對程式仁慈，就是對自己殘忍) (<--那來的俗話?)
(3)在開發過程中了解程式架構 (一知半解)
(4) 其它操作測試工具的技能 (目前我可能在這裏)
下個build 來試驗一下，直接從源頭(規格) 找麻煩，並且保持邪惡的心態(?爆)來Q，希望能真正做到品質保證啦XDDDDD
1 則留言:
有道理喔。請再分享實施後的心得喔。期待中。
不知道這個比喻好不好。傳統的測試觀念，像是學校期末考。範圍就是這學期的內容，到時候會出題來考學生有沒有了解內容。
Agile的測試，是直接洩題給大家準備。期末就是要考這些，只要全答對就是一百分。當然，直接公佈考題的話，為了確保學生有完整學會這門課，出的題目就要很多很完整。最完整的情形是，考題就是全部教材。通過考試，就是把教材的全部內容都印證過一遍。
當然學校教育不能這麼做，這是比喻而已。但是自動測試由於執行速度超快，就可以這麼做。
所以推到極致，變成老師編輯教材，就是在出考題。出考題就是在編教材。
需求規格就是(自動)測試案例。測試案例就是需求規格。Iteration中開發者就是逐步要滿足這些測試案例。
張貼留言