3 months ago

前兩天16,17號,由提出海盜派測試的邰曉梅老師主持,
引領這個敏捷圈的大家聊一聊「隱藏的質量」這個問題

持續的探索

當曉梅老師解釋她自己實作的一個小程式是如何一步一步的進行「探索」時
我才晃然驚覺,她這兩天所講的探索,其實不只是我們一般在軟體開發中進行的測試

我們過往講的測試,就是做驗證,驗證已經做好的東西,是不是功能正確、能如預期般地運作

而她所講述的測試探索,我一開始還狹義的以為只是針對有可能發生的bug進行try and error
但其實她要表達的,是「真正的探索」

「探索」,對未知領域的伸探,盡可能發掘一些有用的資訊。
發掘未知的領域,把未知領域裡的資訊進行過濾,
但未知的資訊未必就能馬上變為已知,未知的有可能是風險,
往往要進行一些小規模的實驗才有辦法把風險中隱藏的訊息曝露出來,
而小規模的實驗其實也是探索的一部份

我試著用下面這個例子來解釋我的理解:


你正在做一個可以讓多個user同時線上使用的系統聊天系統
你發現系統回應的速度,因為user的數量規模日漸增加而有漸緩的趨勢
因此,user數量級的增長將會為系統的穩定服務帶來風險
這是一個 known unknown - 已知的未知之數

雖然知道這是一個風險,但手中卻沒有數據能推斷大概到哪個數量級時,系統就會無法運行
作為營運者現在也很難推測user的增長數目,是否會一直維持與現在相同的增長斜率

又假設為了維持良好的用戶體驗,你要求系統的request回應速度要在1秒之內
所以未知之數已經有:

  • 以現在的系統規模,app request能在1秒內回應的前提下,最多同時可容維上線的user為多少?
  • 同時在線的user數量的增長率為何?
  • 哪一天將會到達這個最多可容納上線人數?

就這樣一個被發現的問題點,就可以延展出這些問題,當然還存在著更多的問題、更多的風險
這是暫時機器無法取代人進行的動作,是一個探索風險、揭露未知的過程

當然,時間與市場不會允許你挖掘出所有的問題,我們也不可能完美解決所有的問題,
但揭露風險是能提高品質的過程,哪些風險需要馬上被解決,哪些可以繼續安放
會是團隊一起進行的決定,讓這些被揭露的風險資訊,為大家建立對這產品的品質共識

與 TDD (Test-Driven Development) 如出一轍

「我每找到一個錯誤,我就去改進我的程式,然後再去探索下一個問題」
曉梅老師介紹完她的實作過程後,我心想:「這就是TDD的思路呀」

永遠為現有的程式找到下一個可能會出錯的情況,圈出的risk boundary
我也並不認為一定要很制式地先寫一個 fail的test case作為開始才算是真正的TDD
死守這種方法論的定義,容易失焦於其能帶來的價值

「挖掘風險」這一精神,我覺得老師講的探索性測試與 TDD 其實是沒有同一種道理,
有時候我覺得TDD 是一種 mindset ,比作為一種方法更為適合。

所以聽完曉梅老師這次分享,讓我更加深信TDD在程式開發上對於風險發掘的影響之深
TDD對應的是開發程式本身
那麼 test and exploration 應該是對應到產品的品質提升

問題不只存在於程式中

曉梅老師一再強調 Checking 與 Testing 本質的不同
那些按著 SPEC, Plan上的驗證動作,填上一個接一個的勾勾,就只是checking 的概念

我當下能理解這個區別,但卻不明白為何曉梅老師要一再強調這個定義問題。
經過兩天的沉澱下來,回想起一路走來的開發經歷以及接上過 David的需求探索入門工作坊,有了一些想法:

checking 固然重要,因為那些是我們已經知道我們必需做好的事情。
但卻容易把產品的品質侷限在這樣的框框當中

以驗證一些UI的正確性為例,
假如在一個包含GUI的產品上,我們需要測試一個 text input field 的正確性,
能否在輸入值後得到預期中的結果,或者在輸入不正確的值後得到比較直覺的錯誤訊息回應
然後繼續把注意力集中在這個 input field中的輸入值當中
但可否會想到除了test case上表列的那些可能性之外的 input呢?
更甚者,這個input field是否有存在的必要?是否存在著別的操作可能也能為user達到同樣的目的?

或許正在進行這項驗證工作的 tester不認為這屬於自己的工作範疇內,那是 UX designer 該注意的
但 假若 developer 已經能為自己所開發的程式負上更多的責任,
而 tester 單純只著眼於程式 debug 層面上 test工作,對於有效提升產品質又能起到多少顯著的作用?

甚麼是隱藏的質量?

當我們開發出一項功能、乃至一個產品時,我們有辦法描述這個功能或產品的品質/質量如何嗎?
質量這個詞,非常抽象,在軟體開發這個領域中,

從開發期的軟體中找到的bug數、coding style一致度、程式的可延展性、可維護性
到產品上線後,遇到錯誤引起無法down time的次數、服務穩定度、修復錯誤所需之時間
再到使用者終端,使用者體驗、安全性議題、市場評價與商業價值等等都可以成為品質/質量的指標

察覺到那些隱藏在背後的品質問題,才能做出差別。

因為自己也還沒看讀過曉梅老師著作的 <<海盜派測試分析>>
或許還沒能正確詮譯曉梅老師對測試的中心思想
以上純粹這兩天聽了曉梅老師分享後,自己所得到的一些反思和見解
若有誤解,還望朋友作出指點糾正

← 2017 AgileTour 暖身場 24Hrs敏捷戰鬥營 - 活動心得#2 - 最難熬的Sprint#0 Tenmax 讀書會 workshop - User Story Mapping →