進度條

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

並不是所有的問題都需要及時解決,順序不對再多的人力都不夠用

作者: Vincent Ke 更新日期:

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

 

 

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

 

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

 

 

pexels-photo-533189.jpeg

 

 

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

 

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

 

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

 

 

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

 

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

 

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

 

 

pexels-photo-1305360.jpeg

 

 

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

 

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

 

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

 

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

 

 

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

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

 

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

 

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

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

 

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

 

 

pexels-photo-1345089.jpeg

 

 

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


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

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧