初探團隊基於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的探索性測試的要點，並感覺到了它的益處。 　　一、由於session，更專一 　　由於每一個session都有肯定的開始和結束時間，通常長度爲一小時、一個半小時或者兩小時，因此在這有限的且不算太長的時間裏，測試人員會更專一，從而效率更高。 　　我清楚地記得，有一天下午咱們小組（4個測試人員）計劃了兩個各一個半小時的session。第一個session結束，當咱們作debrief（下 面會介紹debrief）的時候，有兩我的明確提出下面即將開始的新的session可否改爲一個小時，由於過去的一個半小時太累了，「大腦都要缺氧 了！」固然，剛收穫了近40個缺陷和近30個疑問的這個session，無疑你們都是很辛苦的。可是，從另外一個方面，咱們也看到，平時若是沒有 session，你們的專一程度是否還能夠提升一點呢？對我而言，雖然感到此次和我平時我的作探索性測試的專一程度相似，但在一個集體作探索性測試的氛圍 下，彷佛也更有時間的緊迫感了。我想這就象本身在家作模擬卷和在學校裏和同窗一塊兒模擬考同樣，總有那麼點不一樣的壓力。 　　二、由於charter，強迫思考 　　在一個既定的方向或者說章程（Charter）上必定要發現缺陷，這實際上是強迫你思考和挑戰本身的思惟侷限。 　　我喜歡看釣魚比賽的節目，也感到它和測試的相通之處頗有意思。例如，釣魚的挑戰在於：如何在你已經很是熟悉、以爲無魚可釣的水域找到魚；如何在一個你 不熟悉的水域，快速釣到大魚；若是你能夠自由選擇，你將換到哪一個水域（由於根據經驗你猜測那裏可能有你們夥）？精明的垂釣者不單有專業的釣竿（測試輔助工 具），對天氣、水域（軟件工做環境）和魚生活習性（被測系統的功能）的瞭解，還要有一些很重要的臨場判斷（根據前面幾條魚的大小和難易程度判斷今天在這個 地方釣上你們夥的機率，以決定下一步是繼續在這裏守株待兔仍是立刻轉移）和一點點的運氣。關於運氣，我以爲測試中也必定是有的，可是我更相信機遇或者運氣 是比較垂青有準備的頭腦的。因此，我老是願意花時間去多測測，花心思去少測測。 　　想一想測試中，咱們是否也面臨和釣魚相似的挑戰？如何在你已經測試了一段時間，以爲比較穩定的功能上找到新的缺陷？如何在你不熟悉的模塊，快速找到缺陷？若是一種方法找不到缺陷，接下來該換種什麼樣的思路？ 　　突破本身思惟的侷限，咱們團隊中每一個人都在實踐多種不一樣的方法。好比，探索性測試一書中的各類方法（遍歷法、強迫症法、取消法、超模法。。。），自創 或者借鑑的各類測試的經常使用方法（web測試要點、安全測試經常使用方法。。。）以及Test Explorer工具的小提示等等。 　　當咱們設定全部測試人員都採用同一種方法來測試的時候，報出的不一樣的缺陷每每很是使人印象深入。咱們也在一塊兒分享、總結、積極尋找測試某個軟件的最管用的探索性測試方法是哪一兩個。強迫自我突破，學習他人突破，三個臭皮匠頂個諸葛亮！ 　　三、由於彙報（debrief），團隊力量勝於我的 　　我我的以爲，我的的探索性測試和團隊的探索性測試在流程上最大的差異就是彙報（debrief）。這是一個session結束後的短暫討論環節。咱們 採用的是Jon Bach提出的PROOF模式。PROOF即Past， Results， Obstacles， Outlook， Feelings的首字母縮寫。按照這個形式，咱們會逐個分享過去這個session本身完成的工做、獲得的結果、碰到的困難、接下來須要進行的工做（可 以做爲下一個session的目標）、本身的感受。在這個環節裏，咱們會對一些公共的問題或者大的障礙進行一些溝通，但不會太長時間討論，而主要是讓團隊 成員知曉一些咱們認爲重要的信息。這裏，咱們常常可以發現共鳴或者別人輕易就解釋了咱們的疑惑。若是咱們作的charter是同一性質的，如易用性，那麼 咱們會在每一個人都以PROOF模式作簡要彙報後，按照session報告中缺陷和問題的記錄，快速過一遍每一個缺陷和問題。這對於咱們可以及時學習和借鑑別 人的測試思路，立刻運用到本身接下來的測試過程有必定的幫助。我感到：經過debrief環節的及時溝通和互相學習，咱們將探索測試的精髓也擴展到了咱們 的團隊學習和實踐中，即在一個很短的週期內，學習和執行是融爲一體的，而不是順序的、隔離的。