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 的工作能力
- Business dimension
要有良好的溝通能力，能從客戶端取得與業務問題最重要相關的測試重點。要知道如何產出能讓客戶接受專案產出結果的測試項目。 - Technical dimension
測試者必須要有良好的技術背景，還要有良好的 programming skill，事實上，測試者跟開發者的基本程式設計的技能，應該是一致的。 - DevOps dimension
測試者必須要有將日常測試自動化的能力，還要能整合各種不同的測試工具。
看到這邊，其實都是在談一個軟體團隊的最佳狀態，除了要有能力強大的工程師之外，還要有無所不知的測試員。但其實一般的團隊，並不一定都能有這樣的工作環境。
因為市場決定了產品，市場決定了專案的規模，還不能被證明是有市場的產品，沒辦法取得最佳的人力資源進行開發，更別說有個法力高強的測試員了，基本上，能配置測試員就已經是還算不錯的情況了，到最後如果產品賣得好，程式也已經做完了，該被測試出來的問題都已經解完了，然後會是下一個產品循環。
Behavior Driven Development BDD
關於 BDD，可以參考以下這些文章
簡單地說，BDD 可說是專案 stakehodlers 使用的 TDD，強調用 domain language 撰寫，而非程式設計師實作的測試項目，這會讓測試者能以專案 domain 為焦點，撰寫業務相關的測試項目。
說真的，我並不熟悉 BDD 的實作方式，重點是這種測試的面向出現的時機，確實解決了專案使用者能夠進行自動測試，累積測試案例的一些問題，他們不在只是看著一大本測試案例文件，然後手動一項一項進行測試的測試員。
但要說 BDD 真的能完全取代人工測試的部份嗎？這個其實跟機器人是不是能取代人力應該是類似的問題，所有人都會回答：「不可能！」但能被取代的是無法跟著時代進步的人力，而不能被取代的，是可以更新自己的能力，操作這些新測試工具的人力。
但也要注意，BDD 測試因為多了一層自然語言的設計與解析，增加了開發的成本，在使用時必須要了解，BDD 雖然是 domain expert 的最佳測試與驗證的工具，但 BDD 還是需要程式設計師去實作翻譯與解析的程式，只要是程式都有可能會出錯，也會產生 bug。
Mobile Testing 要注意的事項
Mobile Web Testing
- Responsive web design
- Multiple Browsers
- Simulator/Emulator vs real devices
- single page or pageless design
這跟 browser history 有關係，如果使用者點了上一頁，會不會造成問題 - Testing number of requests and data transfer
確認 server 有沒有提供 js minification, gzipping, lazy loading 或使用 application cache for local storage，這些會影響 client 端能不能順暢地使用網頁 - Automation
Mobile Application Testing
- customer do not compromise on design
測試者必須以代表真實使用者的感受，對 APP UI design 提供建議。 - Developement framework impact on testing
- Native vs hybrid approach
APP 裡面有沒有包含 WebView 會影響實際使用上的感受。 - Device vs simulator dilemma
- Performance matters
- Information is power, how to get it?
收集並分析使用者的使用狀況。 - Testing third party integration and location services
整合 FB API 或是 Location Service API，開發時可用模擬的方式實做，但在真實的環境中測試，結果跟想像的可能大不相同。 - Test automation
- Continuous integration and build distribution
自動且持續的整合與建構
創造力與測試
我們再來看一篇文章：創造力與測試：可否共存？，內容討論到 Agile Tester 該有的基本能力。
文章中提出了一個 Thinking Tester 的名詞，其代表的意義，就是更高等的測試員基本能力要求，從公司的角度來 說，我們該用更好的人力去進行測試模式的設計與開發，而 Agile 工作團隊，並沒有規劃單獨的測試人員，也就是說，我們需要能夠在功能實作與測試兩者能力都能兼具的工程師。
就一個成熟的軟體團隊來說，會有多個開發人員，系統在基本的開發人員自行測試驗證之後，就會進入第一個階段的整合，這時候，不同開發人員開發的功能模組就會有互相呼叫與搭配使用的情境。
或許我們可以讓工程師開發程式之後，互相交換進行功能測試，這種方式既可以避免工程師測試自己寫的程式產生了測試盲點，也可以運用另一個工程師實做程式的經驗與能力，進行系統驗證與測試。
文章中提到，傳統的測試工程師所作的事情，就是一再地重複與重複進行測試案例，在幾次的循環過後，慢慢地就會覺得工作能力遲滯，沒有進步，這也間接造成行政與管理團隊會認定，測試工程師的工作不需要過於高階的人力這樣的狀況。
該怎麼作，沒有絕對的對錯，要怎麼保證軟體品質，各有各的見解與方法，也只能慢慢地根據自己團隊的狀況調整策略與方法了。
沒有留言:
張貼留言