Exploratory Testing的優缺點及適用時機
from Exploratory Testing: Evolution or Revolution?, SVEN SAMBAER
http://www.ctg.com/pdf/exploratory-testing.pdf
Exploratory Testing的優點
(1) 它鼓勵創造性
(2) 它增加機會去找到新的, 未知的bugs
(3) 它允許花較多的時間去測試一些有趣或是複雜的cases
(4) 它的最大好處是使tester能在短時間發現bug, 並且對受測系統做快速的評量
(5) 它能讓你知道系統是否容易使用(如果很難用, 在短時間是不容易找出問題)
(6) 它是可變通, 有彈性的
(7) 它比scripted testing有趣, 因為它不會一成不變
Exploratory Testing的缺點
(1) 它的有限度管理性, 使它很困難被協調和調節
(2) 它只能提供有限的情報, 無法對風險,測試覆蓋,或測試的深度有深入了解
It provides only limited project intelligence, with little insight into risks, test coverage, or test depth.
(3) 它提供有限的test reusability, 以及對於bug的reproducibility也不是很好
(4) 它大量依賴tester的testing skills和domain knowledge
(5) 如果和scripted testing合併使用時, 可能會有redudant test的風險
(6) 它並不提供絕對保證, 最重要的bug一定會被發現
(7) 對於像security testing, performance testing等有特別目的的測試項目, 它並不適用.
(8) 對於需要花時間做複雜的設定, 或是要很久才能看到feedback的測試(例如要跑整夜的測試), 它並不適用.
(9) 當test object是available時, 才適合開始使用它
什麼時候適用Exploratory Testing
(1) 當有新人進來
- ET can make the learning phase an active testing and exploration experience.
(2) 需要做快速的評估
- ET offers fast insight into product quality in the short term when there is no time for test preparation.
(3) 在做scripted testing時, 發現有新東西要去了解
- The new information might suggest another test strategy that would warrant switching to an exploratory mode.
(4) 你需要去確認另外一位tester的工作狀況
- ET lets you explore the feature that he/she has tested.
(5) 當你的team裡面有tester有很豐富的domain knowledge
- Those individuals can be trusted to perform effective testing using ET.
(6) 當smoke test被需要時
- ET lets you determine the maturity and stability of the test object before progressing to large-scale test execution.
(7) 當沒有任何測試的依據時
- ET is useful when there is no documentation or other sources that can define clear, expected results for the tests.
(8) 當你在run agile project時
(9) 當你想要深入調查某個特別的bug
(10) You want to determine the status of a particular risk in order to evaluate the need for ST in that area.
(11) 當在早期, 受測產品還不穩定到可以執行scripted testing時
(12) 在beta時, 你希望customer提供early feedback, 你可以請他們做exploratory testing
(13) 你想要擴大scripted testing的多樣性
- The combination of ST and ET is appropriate for testing features with a high risk and/or priority profile.

personal oppinion: exploratory testing 無法測試"未知的未知-看到 了也不了解"和"未知的已知-沒想到要測", 什麼時候適用Exploratory Testing (1) 當有新人進來-與缺點四衝突(它大量依賴tester的testing skills和 domain knowledge) (12) target Beta group recruiting 會影響test的方法
是的, 任何測試是無法測試"未知的未知-看到了也不了解"和"未知的已知 -沒想到要測". 但是ET強調的是不要只有scripted testing, 若是只有scripted testing, 你測試的東西會只固定在同一個範圍. 所以ET細望你能多try不 同的東西 所以ET的限制是你的想像, 如果你沒有想到當然也是測不到. 至於新人未必是沒有測試經驗的人, 他可能只是對這產品不熟. 即使沒有 經驗的人, 他也可能提供不同的思路, 讓你可能有不同的測試流程產生. 當然我知道你的concern, 確實在很多狀況下, (1)和(4)事衝突的 對於(12)的狀況, customer常常出現我們難以想像的use case, 尤其是 real的operations, 所以ET還是有參考的價值
再review一次適用 2,7和9項說一件事Those are true for SEG maintenance task on legacy code. + 11,12總結是所有的 stage 都有 ET 存在的可能 所以Sr.人可以搞定所有的事 developer write code 不寫文件 tester test without test cases. 溝通只剩下Oral and Tracker TOI SEG 的時候只好交換人員 :)(我是來亂的)
ET不是要強調senior 才能做事. 它當初的背景, 是因為很多人強調test automation, 或是certification 可以解決很多testing的問題. 但是他認為這是錯誤的. 他強調重點還是 要以人為本, 要人能夠思考, 快速反應. 否則再多的test automation, 還是不能解決目前QA所遭遇的難題. 所以ET並不是要不寫文件, 只需口頭報告或追蹤. 應該像agile的宣言一樣 Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 不是右邊的部份不重要, 只是我們更強調右邊的部份. ET不是不要規劃或是文件, 而是更強調QA能夠更加強思考, 及快速反應. 但我也知道有些Engineer會自動強調一些他們不想要的部份, 例如像有些 engineer看完這個宣言後, 會因為自己不想寫文件, 所以就賴agile是不 用寫文件. 所以這就是我們要避免的