在最近的一門課程 - 測試個案設計與分析實戰班, 發現不少參加者是開發人員, 因為公司沒有專職的測試人員, 因此想要來學習如何測試.
聽到這樣的狀況, 真的很為這些工程師和公司感到高興, 我們對於軟體品質還是感到很重視, 願意花時間花錢出來學習. 不會因為公司小, 或者是沒有測試人員, 就放棄質量這一件事.
對於這樣的狀況, 我覺得可以依以下方式來加強公司測試流程:
1. 開發人員自己寫自己程式的自動化
有適度的自動化, 可以在迴歸測試時有很大的幫助. 並且也可以早期抓出一些整合上的問題. 就如同我之間的文章說的, 我們要的是有, 但不是要多, 然後用最簡單的方法天天執行, 然後有錯立刻修復.
2. 開發人員交互進行別人的功能測試
一般開發人員對於自己的程式, 不見得會下重手測試. 有時候更因為先入為主盲點, 抓不出自己設計的盲點. 比較好的方式, 是採取交叉測試, 可以 A 測 B, B 測 C, C 測 A. 一方面可以有不同觀點來驗證, 一方面有可以藉由這樣的測試來熟悉對方的系統, 讓大家多熟悉不同模組.
3. 對於找到的錯誤, 試著加入自動化中
因為我們的自動化剛開始不多, 讓要如何補強呢? 以大多數專案或是公司的狀況, 不容易有時間專職來做這樣的事, 因此我們可以試著當遇到一些 bug 時, 我們因為要修復它, 修復完後需要驗證時, 可以來順便補些自動化來檢查. 這樣量也不會太大, 另一方面也擴大了自動化的範圍.
4. 吃自己的狗食
如果你開發的系統, 可以在自己專案環境就使用, 或者是在公司其他部門使用, 這樣就可以在早期得到使用者回饋. 以及及早利用真實資料來確認系統的正確性.
5. 輕量級測試設計方法
不用依照大公司或是 IEEE 829 的方式來寫測試計劃, 或者開立測試個案. 你只需要寫出你真的會用到的部分. 並且可使用 mindmap 或者 excel 來紀錄 test case 就可以.
在開立 test case 時, 通常來說以 decision table testing 方式為主, 然後搭配上 boundary value testing 和 Equivalence Class Testing, 這樣就可以找出大多數的狀況出來.
另外, 也可以將一些常見狀況的個案整理起來, 例如用到 IP 的輸入要怎麼測試, 遇到 password 的欄位要怎麼測試, 這些基本常見的東西, 可以把 test case 整理起來讓大家日後可以共用.
6. 利用敏捷測試實務
也許你的公司並沒有在實施 agile software development process, 但是在測試方面有些想法倒是可以拿來用用:
(1) 寫完就測
在 waterfall 中是要所有功能寫完才測, 但是你可以嘗試寫完某部分後就開始測試, 一方面讓測試時間可以比較多, 一方面可以讓你早點收到一些回饋.
(2) 利用 spec by example 來釐清需求
要求做到 BDD 可能對很多公司來說不容易, 但是如果可以利用 spec by example 的觀念, 在早期釐清要做的需求是什麼, 這就是功德無量的一件事情. 因為工程師不是沒能力做完, 而是他受不了一直 rework 或是做錯功能.
(3) Exploratory testing
如果你真的沒空開立 test case 或是制定測試計劃, 你可以採用 exploratory testing 搭配 SBTM (session based test management), 在沒有事前規劃下, 又能系統性地執行測試.
希望這些建議可以幫助到你把產品給測試好, 但是沒有所謂的萬靈丹, 你還是要因地制宜.
全站熱搜
留言列表
