QA工程師如何捍衛卓越產品體驗

如何才能幫助開發團隊有效率的降低產品上市的風險，並且得到一個好的效果呢？我們可以從這些方面來實踐：優秀的QA工程師，必須對產品做的事情。

好奇心

對不良的作法提出疑問跟建議

一般我們可能會理解，「聽話」就是請工程師做什麼，他就照著做。如果有了「聽話」的工程師，我們就不需要為了完成一項工作，額外多付出心力，來使其得以推動。然而，一個良好的產品在開發流程裡本來就需要不斷的獲取各方面的回饋，才能持續改善缺點，以交付更有價值的產品為目標。

●團隊領導者並非全知全能，我們需要不同的觀點來輔助，以避免發生錯誤

當有人質疑你的想法或決策時，其實是很好的一件事情。因為這樣，可以幫助團隊更認真地思考自己的想法或決策，是否存在某些問題，讓團隊有機會進行修正。

軟體產業終究還是靠團隊的協同合作來達成目標，人的因素十分重要，即使你在開發過程中犯了一些錯誤，還是能借助發現問題的人，將你從這些錯誤中拯救出來。

●優秀的QA工程師，能適時的對不良的做法提出質疑

面對產品規格與客戶期待之間的落差、系統開發架構不易維護，運作成本太高各種千奇百怪的問題，一個優秀的QA工程師要能適時地提出修改建議，協助團隊導正錯誤的開發內容，越早發現問題，修正成本也就越低。

從優秀到卓越

●多方嘗試，找出非常規思維的Bug

儘管QA手上的許多測試任務看似重複，但機械思維與優秀的QA工程師是截然不同的。人類樂於打破規則，使用者非理性的操作行為，可能導致產品上市後發生一些沒能提前預測到的缺陷。

優秀的QA工程師會表現出這種測試態度，在介面中不支援點擊的地方嘗試進行點擊，看似偏離合乎邏輯的測試項目，實質上是想多方嘗試各種可能性，來降低產品上市的風險。

●正向思考，面對沒提早發現的Bug

在面對產品上市後的Bug時，優秀的QA工程師並不會因為沒提早發現Bug而沮喪，反而會渴望了解為什麼會出現缺陷，找出問題的根源，並提出解決與預防的方法。

定期的分析過往Bug的成因，提出歸納後的結論，並且和團隊討論預防的方法，如調整回歸測試的腳本、增加自動化測試的覆蓋率、大量進行冒煙測試等…，提出有效果的預防方法，幫助提升產品的品質。

徹底測試的決心

對產品負責的態度

QA對於產品的全貌、使用者對於功能的使用方式與期待，是比較了解的。QA被視為「使用者」的代言人，必須把自己當成使用者來撰寫測試腳本。

■「使用者通常會如何點擊廣告？點擊商品圖片，還是點擊Logo？點擊商品圖片與Logo，是否都是打開商品的介紹頁面？」

■「商品折價券的有效時間到12/31，是要設成能在12/31 23:59:59 前使用，還是12/31 00:00:00就過期了？時區GMT+8正確嗎？」

■「全站單日滿3000送300購物金，是結帳時額外將300元購物金存入使用者帳戶，還是直接扣抵消費？當總價不滿3000時，如何讓系統判讀不提供300購物金？」

以上皆是使用者日常對於產品的操作行為，雖然是微小的功能差異，如果真的發生異常行為，卻有可能會造成嚴重的業務損失。

如何防堵Bug，如何做到滴水不漏

產品的開發過程裡，常有無人關心的小地方，如果團隊中從來沒有人想過、測試過，某些Bug就很難被發現。Bug通常就是這樣子被默默地堆疊起來，直到有一天在交互作用的影響下，產生了嚴重的業務損失，才會被人們注意到。

我們來觀察一個實際的案例：2018-09-29 Facebook表示，近5000萬用戶因嚴重的安全漏洞而受到攻擊（資料來源：https://bit.ly/3eCiBTd）。

該公司稱，Facebook工程師於9月25日週二發現了這個嚴重的漏洞，並於週四進行了修補。受到影響的用戶會收到Facebook的通知，這些用戶會被登出，並需要重新登入。

Facebook的漏洞，來自於三個小Bug的交互作用：

(1)第一個錯誤是，使用「以瀏覽身分查看」功能時，「影片上傳」功能根本不應該出現。

(2)第二個錯誤是，當「啟用影片上傳」功能時，會產生一個Access Token，但實際上根本不應該產生。

(3)第三個錯誤是，當某A使用「以瀏覽身分查看」功能檢視某B在他人眼中的樣子時，「影片上傳」功能產生的是某B的Access Token，並非是某A自己，這將導致某A可以登入某B的帳號存取或修改資訊。

如果團隊中有人發現上述3個Bug裡的其中一個，並完成修復，那麼漏洞就無法產生，也就能避免嚴重的商業損失。

●如何防堵Bug，如何做到滴水不漏：

(1)增加Unit Test（單元測試）涵蓋率，確實進行Code Review（程式碼審查）。

(2)定期的回歸測試中，以亂數抽樣或是挑選近期較少執行的測試腳本，進行測試。

(3)定期針對特定主軸進行探索性測試，以非常規的思維進行測試。

提早介入發現問題，降低修復成本

品質是「設計」出來，而不是「測試」出來的。讓我們從測試和開發的角度來看，如何在開發流程裡，提早建立產品交付的品質。

●建立測試流程提早掌握產品交付品質

從測試的角度看，要更好的掌握產品交付的品質，QA就要盡可能提早干預RD寫出Bug，最好是讓Bug被扼殺在搖籃裡。

產品經理、RD、QA應該同時參與需求討論會議，澄清需求。另外將關鍵測試的項目，作為需求的一部分，當RD交付需求時能先完成關鍵測試，減少QA日後測試到完全無法運作的功能，從開發階段提高團隊的運作效率。

●建立開發流程提前最佳化產品交付品質

從開發的角度看，提高程式碼的品質可以有很多種方式：

(1)提高自我測試意識，透過單元測試或靜態程式碼分析，掃描程式碼是否有不符合規則的地方，提升程式碼的品質。比如資安裡最常見的風險就是資料隱碼攻擊（SQL Injection），因此有專門的規則是在比對程式碼哪裡使用了可能導致SQL Injection的程式碼。

(2)真正理解需求和技術架構，進行Code Review或者Pair Programming（結對開發），來提升程式碼的品質。

開發流程裡的產品交付品質是屬於測試左移的範疇，例如：QA在參與需求會議時提出問題，與列出關鍵測試項目時，其實就已經開始在進行測試了。為什麼我們要測試左移呢？因為發現問題的時間越晚，其修復的成本就越高。

如果我們能把測試活動向左移動，那麼就意味著修復成本將大幅下降。但這並不容易實踐，想要把大部分的測試放在單元測試裡完成，需要依賴成熟的開發環境和極其資深的開發團隊。

除了大量進行單元測試之外，培養團隊的測試賦能，也是實踐測試左移的一種方法。

賦予RD自主QA的意識與基礎技能

培養測試賦能，從字面上的解釋是，QA給RD賦於某種測試能力，讓RD有能力完成測試，例如：降低測試門檻、使用自動化測試工具、方便取得測試數據、養成測試意識。

舉個例子，RD正在開發的功能是個產生報表的UI，報表在呈現資料的當下，會針對不同的數值大小，在表格裡填上相對應的背景顏色。QA事先準備好各式各樣的報表測試資料與自動化測試的開發，當RD完成功能開發後，可以點擊一個按鈕將測試數據匯入資料庫，再點擊一個按鈕就開始進行測試，一陣子之後就可以看到數值大小所對應到表格顏色的測試報告。RD其實並不需要懂測試數據的設計、自動化測試的開發、測試報告的編排，但是RD依然可以快速完成測試（門檻低），只要他養成測試習慣（培養測試意識）。

優秀的QA工程師協助團隊實踐測試左移時，並不會將測試的負擔轉嫁給RD。相反的，而是幫助RD寫出更高品質的程式碼，更高效率地完成開發。（本文摘錄整理自《軟體測試實務[I]》第二章，作者／郁家豪，Appier沛星互動科技）

圖片來源_博碩文化

 書名  軟體測試實務：業界成功案例與高效實踐[I]

李信杰／主編；江仁豪、宋濤、李佩蓉、林書緯、郁家豪等／合著

博碩文化出版

定價：650元

 作者簡介 

圖片來源_成功大學

李信杰（本書主編）

現任國立成功大學計中/資訊工程學系副教授，亦為全球最熱門開源測試軟體Selenium IDE V3、Katalon Recorder與Qualys Recorder原型創造者，目前國際上超過80萬名軟體測試人員受惠。

李教授著有80餘篇國內外期刊與會議論文、獲得10餘項最佳論文獎，並擔任90餘項國內外學術服務職務。李教授熱愛軟體工程實務型研究，著迷於鑽研科學化的軟體測試方法。