初探團隊基於session的探索性測試

　　如果你是一名測試人員，那麼不管你對探索性測試的瞭解是多是少，我肯定你一定用過探索性測試的方法。想想看，你是否曾經這樣測試過？不僅僅按照測試案 例或者指令碼上寫什麼，就完全使用那一套相同的資料、一模一樣的流程，而是根據你執行時的所見，臨時有所想和所動，進行一定程度的自由發揮？我想你肯定有 過，這就是探索性測試，它將你的測試與純基於指令碼的測試（script. based testing）區分開來。而這種自由發揮，因為是有大致方向和範圍的，所以也與完全盲目亂點的猴子測試（monkey testing）不同。
　　換言之，因為你是人，所以你比猴子和機器人都聰明，你懂得在學習中不斷完善自己，而不是漫無目的或者按圖索驥。因為你是測試人員，所以探索性測試是你 必備的職業技能。而如果不經過一定的理論指導和系統實踐，我想憑著那點探索的本能，你還不足以成為一名高效的測試人員。如果想快速提高探索測試的技能，我 認為最好的方法是和你測試組的夥伴一起來實踐和提高，而不是一個人練習。如果你所在的團隊還沒有過這方面的實踐，那麼你可以從本文當中瞭解到我們團隊中基 於session的探索性測試的實踐和感悟。
　　為什麼我們選擇基於session的探索性測試？
　　基於session的探索性測試在2000年由James Bach和Jonathan Bach兄弟倆建立。這裡的Session其實就是一段指定的時間，比如從8：30到10：00的一個半小時。探索性測試可以不基於session。至少 在讀完J Whitter的“探索性測試”一書後我完全沒有覺得session是探索性測試中的一個關鍵詞。但是查閱探索性測試資料，你會發現實踐中的探索性測試很 多都是基於session展開的。我們實踐了以下三個基於session的探索性測試的要點，並感受到了它的益處。
　　1、因為session，更專注
　　因為每個session都有確定的開始和結束時間，一般長度為一小時、一個半小時或者兩小時，所以在這有限的且不算太長的時間裡，測試人員會更專注，從而效率更高。
　　我清楚地記得，有一天下午我們小組（4個測試人員）計劃了兩個各一個半小時的session。第一個session結束，當我們做debrief（下 面會介紹debrief）的時候，有兩個人明確提出下面即將開始的新的session能否改成一個小時，因為過去的一個半小時太累了，“大腦都要缺氧 了！”當然，剛收穫了近40個缺陷和近30個疑問的這個session，無疑大家都是很辛苦的。但是，從另一個方面，我們也看到，平時如果沒有 session，大家的專注程度是否還可以提高一點呢？對我而言，雖然感到這次和我平時個人做探索性測試的專注程度類似，但在一個集體做探索性測試的氛圍 下，似乎也更有時間的緊迫感了。我想這就象自己在家做模擬卷和在學校裡和同學一起模擬考一樣，總有那麼點不同的壓力。
　　2、因為charter，強迫思考
　　在一個既定的方向或者說章程（Charter）上一定要發現缺陷，這其實是強迫你思考和挑戰自己的思維侷限。
　　我喜歡看釣魚比賽的節目，也感到它和測試的相通之處很有意思。例如，釣魚的挑戰在於：如何在你已經非常熟悉、覺得無魚可釣的水域找到魚；如何在一個你 不熟悉的水域，快速釣到大魚；如果你可以自由選擇，你將換到哪個水域（因為根據經驗你猜想那裡可能有大傢伙）？精明的垂釣者不單有專業的釣竿（測試輔助工 具），對天氣、水域（軟體工作環境）和魚生活習性（被測系統的功能）的瞭解，還要有一些很重要的臨場判斷（根據前面幾條魚的大小和難易程度判斷今天在這個 地方釣上大傢伙的機率，以決定下一步是繼續在這裡守株待兔還是馬上轉移）和一點點的運氣。關於運氣，我覺得測試中也一定是有的，但是我更相信機遇或者運氣 是比較垂青有準備的頭腦的。所以，我總是願意花時間去多測測，花心思去少測測。
　　想想測試中，我們是否也面臨和釣魚類似的挑戰？如何在你已經測試了一段時間，覺得比較穩定的功能上找到新的缺陷？如何在你不熟悉的模組，快速找到缺陷？如果一種方法找不到缺陷，接下來該換種什麼樣的思路？
　　突破自己思維的侷限，我們團隊中每個人都在實踐多種不同的方法。比如，探索性測試一書中的各種方法（遍歷法、強迫症法、取消法、超模法。。。），自創 或者借鑑的各種測試的常用方法（web測試要點、安全測試常用方法。。。）以及Test Explorer工具的小提示等等。
　　當我們設定所有測試人員都採用同一種方法來測試的時候，報出的不同的缺陷往往非常令人印象深刻。我們也在一起分享、總結、積極尋找測試某個軟體的最管用的探索性測試方法是哪一兩個。強迫自我突破，學習他人突破，三個臭皮匠頂個諸葛亮！
　　3、因為彙報（debrief），團隊力量勝於個人
　　我個人覺得，個人的探索性測試和團隊的探索性測試在流程上最大的差別就是彙報（debrief）。這是一個session結束後的短暫討論環節。我們 採用的是Jon Bach提出的PROOF模式。PROOF即Past， Results， Obstacles， Outlook， Feelings的首字母縮寫。按照這個形式，我們會逐個分享過去這個session自己完成的工作、得到的結果、碰到的困難、接下來需要進行的工作（可 以作為下一個session的目標）、自己的感覺。在這個環節裡，我們會對一些公共的問題或者大的障礙進行一些溝通，但不會太長時間討論，而主要是讓團隊 成員知曉一些我們認為重要的資訊。這裡，我們經常能夠發現共鳴或者別人輕易就解釋了我們的疑惑。如果我們做的charter是同一性質的，如易用性，那麼 我們會在每個人都以PROOF模式做簡要彙報後，按照session報告中缺陷和問題的記錄，快速過一遍每個缺陷和問題。這對於我們能夠及時學習和借鑑別 人的測試思路，馬上運用到自己接下來的測試過程有一定的幫助。我感到：透過debrief環節的及時溝通和互相學習，我們將探索測試的精髓也擴充套件到了我們 的團隊學習和實踐中，即在一個很短的週期內，學習和執行是融為一體的，而不是順序的、隔離的。
本文轉自：