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就無法測試, 我會把它當成是一種警訊, 代表我們開發軟體的方式, 某些地方需要做些修改.
我想，並非無法測試，只是測出來的東西，和實際產品，一定會有落差， 如果要籍由溝通，這也是 OK，但是這樣耗費的時間，那也是一種成本， 而且是難以量化和估計的成本。這種不確定的變因，對 RD 和 QA 團隊， 都是一種風險。
可是就算有文件, 還是會有落差, 不是嗎？ 在大多狀況下, 文件通常也是不會及時更新, 或是從不更新的 此外你拿到文件的時間, 也是蠻後面的, 不是嗎？並且拿到的時候, 我 想看不懂的機率應該也不小, 這時候還是要花時間來來回回溝通 所以在agile中, 它認為不管有沒有文件, 重點是在於有沒有及時溝通. 你可以先溝通, 在後捕文件. 讓雙方有共識, 可以及早得到feedback. 以前分RD, QA兩種role的方式, 會導致大家容易已自身role的角度出 發, 比較容易撇清責任, 比較容易只考慮局部最佳化, 可是往往忘了整 體最佳化. 可是大家應該要考慮的, 是否這樣做對團隊最有利, 而不是對各個role 最有利. 不過你講的一些的成本, 確實是個問題, 或許以後不要分RD, QA, 反正 這麼多事情, 就由這些人一起來處理, 也許大家就會考量是整體的部份, 而不是個別role的部份
認同有QA說沒有spec就無法測試, 的確是一種警訊，代表很多地方的信任破裂，可能公司團隊面臨長達3~X年的文化傷害 人生為止的經驗有： 1. PM正在框資源，PM也還不確定有沒有RD資源，也沒有spec的狀態下，請求評估時程。 * 該行為導致其他PM更拿不到資源，也會這樣開始瘋搶資源 2. 在很特別的Agile流程下，在根本還沒有source code，RD就已經提交測試，自動化測試report顯示Fail，要求QA需要手動列bug，導致 autotest QA天天寫bug issue，原因一樣，該功能尚未實作。 3. PM表示不知道該產品有沒有客戶，任何客戶需求請QA自行想像。此時RD還會跑來問QA有沒有Product spec，不然怎麼進行autotest? 4. PM支持RD不需要解沒有spec的bug，當exploratory testing找到問題時，請PM補上spec的時間需要大量來來回回。多數情況是PM認為QA只是負責記錄現況，因此RD所設計的東西沒有bug。加上修改spec可能會導致RD需要修改東西，所以會要求QA用測得過的方式來驗證spec可行。 5. 公司本來就不是靠軟體賺錢的，但想轉型成軟體為主的公司。初期支持大量做軟體，賺不賺錢沒關係的想法。 6. RD和PM會談好不和QA說有什麼隱藏功能，怕測試時程太長，會影響出貨。 7. 會有隱藏功能的原因在於，該功能只完成client的服務，還沒有server。所以希望先出有client功能的產品出去，未來等server架設好，再一同和QA、客戶通知。 8. QA有時候很想一起加入design，但RD和PM特別不想讓他們加入。 9. 公司內部分單位的文化是，只要最後客戶驗收測試通過。即便本來QA有驗出問題，需要修改report為ALL PASS，至少不能有Major bug issue顯示fail。
不就是PM把自己該做好的工作扔給RD QA做嗎？ 專案越大牽涉的人員越多，討論所帶來的成本就越高，需求的同步也就越混亂