2017年7月6日

測試的方向選擇

又默默地過了一年.... 

做了一陣子 test infrastructure development 回來重做測試規劃, 可以說也有些體會, 或者說發現一些之前覺得理所當然的東西現在要重新整理一下思考邏輯.

假設有一項測試工作交代下來, 要做之後半年到一年間的規劃, 我們應該做些什麼呢? 

時間跟資源(包括人力以及開發的時間)是做規劃的重要依據, 但還是有些事情在這之前需要先釐清.

好比說產品的方向, 當然可以是產品經理跟使用者體驗設計師的工作, 但是沒有這個方向在做風險評估上會有問題, 即是在問題嚴重程度上會有歧見.

在縮短上線時間為第一目標的前提之下, 我們其實要從一些營運上的角度來思考.

  • 什麼功能是要99.99%可用的? 
  • 什麼功能中斷服務一陣子使用者是可以接受的? 
  • 如果這個功能無法使用了, 我們可以做些什麼? 較低品質但可以維持功能使用? 提示使用者重啟服務? 自動回復並屆時通知? 
  • 即使上線了, 是不是也有方法定期監測功能是否穩定? 
  • 上線後發現問題, 該怎麼解決? 能直接觸發回溯至前一個穩定版本? 
  • 離線或不支援類似功能的話應該怎麼辦? 
這些看起來不是測試的問題, 然而掌握到話無疑可以在測項的建立與取捨上有更好的發揮. 

在有開發資源的狀況下, 我們還可以從測試設施的角度多思考一點.

  • 現有自動化的設施是否完備? 
  • 自動化工具是否有改善空間, 以減少工程師花在上面的時間? (一個例子是, 如何讓自動測試可以在合理的時間內跑完, 像是30分鐘?) 
  • 測試方法上是否 現有的驗證方法是否可靠? 
  • 有沒有更有效的方法驗證並減少錯誤? 
在軟體的方向越來越多元的現在, 軟體品質漸漸從這種多元中抽出模式, 如何快速地理解產品及服務的內容與本質, 兼顧上線後的規劃, 做測試架構才能由針對產品本身走向更普遍可用的服務.