iT邦幫忙

DAY 26
7

如何提升系統設計品質 - 技術與工具以.NET為例系列 第 26

[如何提升系統品質-Day26]測試 - 問題單該提供的資訊

身為測試人員(不管職位為何,只要是負責這個task的人), 有很多東西是你應該要知道,而且得要提供的資訊。

當測試到一個問題,可能是需求面、流程面、功能面、呈現面、操作面、效能面、安全面等等相關的問題,但到底應該要提供哪些資訊,才能幫助Devs修復Defact呢?這篇文章就做點小整理,供大家參考一下。

[如何提升系統品質]系列文章連結
測試目標所在
開一張問題單出來,以問題單分類來說應該要先知道:
1.在哪一個專案底下哪一個模組
2.摘要應該要附上該網頁的名稱,甚至檔名或功能規格名稱
3.問題來源階段為何(可以幫助Devs知道是哪個時間點程式的問題)

問題單該提供的資訊
如果提供的資訊不完整,那就不要預期問題單解決的速度有多快,品質有多好。
1.哪一支網頁(程式)
2.進行了什麼操作
3.什麼時間
4.發生了什麼問題
5.以前有沒發生過
6.其他人有沒發生過
7.是error,還是failed,也就是程式掛了,還是資料錯誤,還是畫面不如預期,還是速度太慢,還是版面問題,還是規格異動
8.測試環境的OS、browser版本資訊,甚至NB的廠牌型號(追蹤OEM安裝的問題),沒問題的環境資訊也應該要提供
9.附上取得到的log資訊(包括可能畫面上的後門),js error,或出問題的檔案在哪
10.擷取畫面,甚至錄製操作流程
11.協助重現問題資訊
12.如果可以,最好可以取得測試資料

Dev修復Defect後,應該提供的資訊
1.問題原因
2.修復方式
3.可正常運作的畫面或錄製流程檔
4.針對問題原因test case所撰寫的Unit Test的程式碼,以及測試結果。

結論
在資訊業裡,我想整個專案團隊,都稱的上是資訊人員,從PM、SA、SD、PG、工讀生都是如此。

既然是資訊人員,就無法避免學習資訊技術相關的知識。不會或不懂技術與工具,不是藉口,整個團隊都是為了努力快點解決問題,與其增加分析和技術人員之間的溝通成本,不如增加學習成本,對整間公司未來在這部分的成本才得以控制。

測試,是門學問,雖然Monkey test是幾乎一定要的,但不代表腦袋和作業程序,也跟猴子一樣。怎麼樣測試地精準,具代表性,提升品質,加速解決問題,避免重複測試成本,都是很重要的功課。

一個好的測試人員,開出來的問題單,會讓developer覺得感動。

補充
一個Dev寫好的程式,應該先經過自我檢查、code review以及自我測試,當然,也應該包括自己程式相關的Unit Test。

這邊附上一張圖是Dev交付程式時可以自我review的,僅供參考。


上一篇
[如何提升系統品質-Day25]測試 - 自動化測試經驗分享
下一篇
[如何提升系統品質-Day27]設計 - Aspect-oriented programming(AOP)
系列文
如何提升系統設計品質 - 技術與工具以.NET為例30

尚未有邦友留言

立即登入留言