是挑剔還是找碴？從產品開發面探討QA堅守的底線

在上一篇文章中，小編已經針對「QA」的角色，以及QA在一個敏捷式開發團隊中，所代表的重要性，然而，在各種不同的公司組織之中，QA不一定會實際歸屬於開發團隊之中，像小編曾經任職的公司中，就有以績效為主(找到Bug越多收費越貴)的QA外包公司合作，也有QA身屬團隊之中的一員的合作模式，甚至是「PM自己動手兼QA的經驗」。

 

 

但QA的價值，並非僅只是在品質保證上畫押，而是應該要把自己投入在整個產品的開發中，擔任守護門神的角色。而本篇文章，將會以產品開發的角度，來對QA的實際工作與價值，作出更詳細的介紹

 

「在定義異常前，先討論什麼行為是合乎規格與例外」

 

 

 

 

在前文中，有提及到QA參與開發團隊的重要性，當PM從User Story 討論出每一項使用者行為的流程時，都會針對正流程去作出定義，舉凡登入功能為例，情境一定是當使用者輸入帳號與密碼時，就可以完成登入動作，而這就是所謂的事件正常流。

 

但規格並非只是針對所有正常流程去作出定義，而是必須針對每一個「其他」事件流程去作出定義，例如當使用者僅輸入帳號或密碼時（表示另外一個欄位為空時），是否要讓使用者進行登入操作？若是可以，那接下來衍生的兩種情境，是否就要有相對應的Dialog來提醒使用者呢？

 

所以在這樣的討論之中，就會繪製出一個完整的事件流程圖，而一份完整的規格，當然就是需要涵蓋出正常流程與例外處理，而並非在規格內記載，或是結果不符合規格預期時，才能被定義為「異常」，例如當你只輸入帳號，卻跳出密碼不正確的錯誤提醒時，就是開出Bug票的時機了

 

 

所以當產品的規格愈趨明確的同時，QA夥伴們也會依據這些準則列出所謂的測試項目（簡稱測項），儘管越多的測項，表示對於異常事件測試的涵蓋率會愈趨完整，但也同時意味著驗證時間與產品上線的時程，也會同步拉長開發成本。

 

「沒有最完美的產品，只有最低上線標準」

 

承上，當產品開發進入尾聲，並進入QA驗證階段時，身為PM最頭痛的，無非就是看到滿滿的Bug海，但難道Bug沒解完產品就不能上線嗎？就像每天都會有髒衣服需要更換，但難道衣服一髒就要洗嗎？這樣我們不是每天洗衣服就飽了嗎？

 

 

 

 

而Bug其實和需求一樣，也會有所謂的Priority，也就是優先程度之分，通常QA夥伴們都會有一道自己的道德底線，來判斷這些Bug的影響範圍和嚴重程度，像小編自己的道德標準就可以分為下列三種。

 

1.「心頭肉」－重置率百分之百，並且會造成產品異常導致嚴重Crash而無法使用

 

這種類型的Bug，就像埋在路上一定會踩到的地雷，儘管每一個User的使用情境和行為都不完全相同，但我們認知中的「罕例」，可能隨著活躍用數的規模而產生變化。

 

我們試想儘管只有1%的使用者會踩到這個地雷，但如果今天你的用戶有五百萬，那這個1%所代表的實際用戶量，可就不容小覷了！

 

 

2.「下次再修」－明顯異常但不影響使用行為（或是有其他替代方案）

通常在討論Bug時，最常聚焦的重點就是重置率，舉例因網速較慢才會發生的這種機率性異常，就可以視為下次再修的範疇。又或著是異常後卻不影響功能使用，例如商品排序價格由低到高，但出來的結果不符預期時，像這種類型的Bug就屬於尷尬型角色，很常會讓人猶豫不絕是否要延遲上線，對吧？

 

但退一步想，儘管有功能面上的異常，但卻不影響整體的使用行為，那對於上線標準的判定上，就不應該有所謂的模糊空間，那不如就放寬心吧，記得要排進下一次開發的待辦事項清單。

 

3.「有空再修」－不好的使用者體驗，但無傷大雅的Bug

例如錯誤訊息顯示有誤，icon圖示解析度不夠..等等，這些會讓使用者擁有疑慮，但對使用上完全無傷大雅的異常，理論上就不該成為上線判定的阻礙囉。

 

所以QA在產品中的重要性，並非只是找Bug的測試員或是產品的品質防線，而是應該可以從規格面，去思考每一個例外處理的重要性，以及檢驗出的Bug嚴重性與影響範圍，但光是這樣還不夠，你不論是手動測試抑或是自動化測試，只要能夠在團隊開發中的每一個環節，提早預防找到bug的可能性，那你絕對是一個稱值的QA。

 

 

 

 

最後，世界上「沒有完美的產品」，有Bug絕對是必然，但如何有調有理地重現，並取其輕重讓團隊擁有最大獲益並消耗最小成本，才是團隊中QA的價值所在。

最後，如果你喜歡我們的文章，別忘了到我們的FB粉絲團按讚喔!!