QA的迷失: "沒有spec我們無法進行測試"
QA Myth #1: “I can’t work without a spec!”
http://testertales.blogspot.com/2009/08/qa-myth-1-i-cant-work-without-spec.html
Monday, August 3, 2009
在我們團隊中, 我常聽到一種抱怨, 就是design spec寫的很差, 或者是很晚才拿到它們. 這是因為在微軟中, PM是負責撰寫詳細的spec, RD則是來實作它們, 而tester則是用它來開立測試個案. 因此你可以想像在這種模式下, 如果spec沒有產生, tester會非常慘, 因為他捫根本無法知道feature在做些什麼.
不要誤會我的意思, 即使是一個agile的團隊 它們也需要設計文件來告訴他們一些事情, 可以經由mail, 白板, 或是走廊上的談話等方式來得到. 但是若是tester被鎖定, 若是沒有spec就無法做事, 這將會是一個非常不好的QA 文化.
在此我有兩個問題:
The belief that a full blown specification is required to successfully test a product.
The belief that a specification is something that happens externally from QA.
對於第一個問題, 我認為這是一個好的tester需要具備的技能. 如果你沒有書面的spec你要怎麼辦呢? 其實你還有source code, 你還知道feature要解決的客戶的問題是什麼. 此外, 你可以找團隊中其他成員(Dev, QA, PM, UE)來討論. 因此, 你所需要的是把你自己變成客戶, 從客戶的角度來想問題, 來看看這個東西是否滿足你的期望, 如果沒有, 則提出問題來. 如果有太難使用的問題, 那也把它提出來.
所以關鍵是, 你必須和你的團隊常常討論. 看看是否有任何功能你不知道的, 還是說有任何地方是有一些known issue存在的, 你會覺得這些事情還好嗎? 還是其實是很不滿意的. 這就是我為什麼喜歡exploratory testing的原因, 因為它需要隨時不斷調整, 來查看什麼地方還有問題.
第二個問題我相信是跟文化有關. 當QA開始等待或是要求spec一定要寫, 他們才能做事, 這時候表示他們內心想回到waterfall的工作模式. 這是非常微妙的, 他們會說: "看, 參與設計不是我的事情, 你應該告訴我妳打算把程式設計成怎樣, 好讓我跟你講要怎麼測試. 不要遺漏任何細節, 否則我會漏掉一些測試的scenarios". 可是一個好的QA, 他應該不是這樣的. 他應該也要加入design, 提供他所遇到的問題和想法, 以及知道什麼東西被實作.
所以當我聽到有QA說沒有spec就無法測試, 我會把它當成是一種警訊, 代表我們開發軟體的方式, 某些地方需要做些修改.
留言列表
