![](https://s4.itho.me/sites/default/files/itshu_zhai_-1p-ruan_ti_ce_shi_shi_wu_-960.jpg)
如何才能幫助開發團隊有效率的降低產品上市的風險,並且得到一個好的效果呢?我們可以從這些方面來實踐:優秀的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餘項國內外學術服務職務。李教授熱愛軟體工程實務型研究,著迷於鑽研科學化的軟體測試方法。
熱門新聞
2024-09-06
2024-09-06
2024-09-06
2024-09-06
2024-09-06
2024-09-06
2024-09-06
2024-09-06