2015/6/8

Perspectives On Agile Software Testing 展望敏捷軟件測試

ThoughtWorks 在 selenium 誕生十週年的時候,發布了一份 56 頁的文件 ebook: Perspectives On Agile Software Testing,除了因為 webdriver 的自動化解決了網頁測試的問題,重要的是 Open Source 的策略,讓 selenium 有無可取代的地位。

Test Pyramid

測試金字塔 TestPyramid 是 Martin Fowler 提出的測試架構,他認為測試應該由底層的程式元件 Unit,到 Service Level,最後是 UI 測試,像金字塔一樣由基礎往上堆疊。

糟糕的測試模式,是像冰淇淋 ice-cream cone 一樣,太過於重視 UI,End User 測試,忽略了底層的 Unit Test,這也是一般的軟體專案最常見到的狀況。



另一種 ani-pattern 是開發跟 QA 單位兩個單位平行運作,這會造成 Service Level 的重複測試,以及 UI 測試混亂的狀況。

ThoughtWorks 認為 Test Pyramid 應該是像這樣的圖一樣,上下夾擊的測試模式,但這必須讓開發與QA團隊,兩個單位能夠充分合作的條件下,才能完美執行的測試策略。



Agile Tester 的工作能力

  1. Business dimension
    要有良好的溝通能力,能從客戶端取得與業務問題最重要相關的測試重點。要知道如何產出能讓客戶接受專案產出結果的測試項目。
  2. Technical dimension
    測試者必須要有良好的技術背景,還要有良好的 programming skill,事實上,測試者跟開發者的基本程式設計的技能,應該是一致的。
  3. DevOps dimension
    測試者必須要有將日常測試自動化的能力,還要能整合各種不同的測試工具。

看到這邊,其實都是在談一個軟體團隊的最佳狀態,除了要有能力強大的工程師之外,還要有無所不知的測試員。但其實一般的團隊,並不一定都能有這樣的工作環境。

因為市場決定了產品,市場決定了專案的規模,還不能被證明是有市場的產品,沒辦法取得最佳的人力資源進行開發,更別說有個法力高強的測試員了,基本上,能配置測試員就已經是還算不錯的情況了,到最後如果產品賣得好,程式也已經做完了,該被測試出來的問題都已經解完了,然後會是下一個產品循環。

Behavior Driven Development BDD

關於 BDD,可以參考以下這些文章

  1. 行為驅動開發 wiki
  2. TDD vs. BDD

簡單地說,BDD 可說是專案 stakehodlers 使用的 TDD,強調用 domain language 撰寫,而非程式設計師實作的測試項目,這會讓測試者能以專案 domain 為焦點,撰寫業務相關的測試項目。

說真的,我並不熟悉 BDD 的實作方式,重點是這種測試的面向出現的時機,確實解決了專案使用者能夠進行自動測試,累積測試案例的一些問題,他們不在只是看著一大本測試案例文件,然後手動一項一項進行測試的測試員。

但要說 BDD 真的能完全取代人工測試的部份嗎?這個其實跟機器人是不是能取代人力應該是類似的問題,所有人都會回答:「不可能!」但能被取代的是無法跟著時代進步的人力,而不能被取代的,是可以更新自己的能力,操作這些新測試工具的人力。

但也要注意,BDD 測試因為多了一層自然語言的設計與解析,增加了開發的成本,在使用時必須要了解,BDD 雖然是 domain expert 的最佳測試與驗證的工具,但 BDD 還是需要程式設計師去實作翻譯與解析的程式,只要是程式都有可能會出錯,也會產生 bug。

Mobile Testing 要注意的事項

Mobile Web Testing

  1. Responsive web design
  2. Multiple Browsers
  3. Simulator/Emulator vs real devices
  4. single page or pageless design
    這跟 browser history 有關係,如果使用者點了上一頁,會不會造成問題
  5. Testing number of requests and data transfer
    確認 server 有沒有提供 js minification, gzipping, lazy loading 或使用 application cache for local storage,這些會影響 client 端能不能順暢地使用網頁
  6. Automation

Mobile Application Testing

  1. customer do not compromise on design
    測試者必須以代表真實使用者的感受,對 APP UI design 提供建議。
  2. Developement framework impact on testing
  3. Native vs hybrid approach
    APP 裡面有沒有包含 WebView 會影響實際使用上的感受。
  4. Device vs simulator dilemma
  5. Performance matters
  6. Information is power, how to get it?
    收集並分析使用者的使用狀況。
  7. Testing third party integration and location services
    整合 FB API 或是 Location Service API,開發時可用模擬的方式實做,但在真實的環境中測試,結果跟想像的可能大不相同。
  8. Test automation
  9. Continuous integration and build distribution
    自動且持續的整合與建構

創造力與測試

我們再來看一篇文章:創造力與測試:可否共存?,內容討論到 Agile Tester 該有的基本能力。

文章中提出了一個 Thinking Tester 的名詞,其代表的意義,就是更高等的測試員基本能力要求,從公司的角度來 說,我們該用更好的人力去進行測試模式的設計與開發,而 Agile 工作團隊,並沒有規劃單獨的測試人員,也就是說,我們需要能夠在功能實作與測試兩者能力都能兼具的工程師。

就一個成熟的軟體團隊來說,會有多個開發人員,系統在基本的開發人員自行測試驗證之後,就會進入第一個階段的整合,這時候,不同開發人員開發的功能模組就會有互相呼叫與搭配使用的情境。

或許我們可以讓工程師開發程式之後,互相交換進行功能測試,這種方式既可以避免工程師測試自己寫的程式產生了測試盲點,也可以運用另一個工程師實做程式的經驗與能力,進行系統驗證與測試。

文章中提到,傳統的測試工程師所作的事情,就是一再地重複與重複進行測試案例,在幾次的循環過後,慢慢地就會覺得工作能力遲滯,沒有進步,這也間接造成行政與管理團隊會認定,測試工程師的工作不需要過於高階的人力這樣的狀況。

該怎麼作,沒有絕對的對錯,要怎麼保證軟體品質,各有各的見解與方法,也只能慢慢地根據自己團隊的狀況調整策略與方法了。

Reference

書評 - 《展望敏捷軟件測試》