Firefox OS 測試流程大揭秘

fxos

今天就聽我這小小測試工程師,娓娓道說 Firefox OS 快樂的工作史!!
這根本可以媲美澳洲大堡礁的工作阿!~This is really good and happy job in Taiwan!!!

troll_2…你還等什麼,快點加入謀智台灣阿,就缺你一個!
~以上,工商廣告時間結束!

——————————————————————————————————————————-

讓我們開始進入主題吧!在早期 Firefox OS 測試,主要採用了 Winston Royce 在1970年提出的 Waterfall model[1] 來測試 Firefox OS ;該模型給出了固定的順序,將生存期活動從上一個階段向下一個階段逐級過渡,如同流水下瀉,最終得到所開發的軟體產品。如下圖。

Waterfall

圖一、Waterfall process – 圖片引用自 tomfishburne.com[2]

但是經過 Firefox OS v.1.0.x 到 v.1.1.0 的版本釋出後,我們發現這個開發程序不足以應付現有廠商的需求,也無法快速反應工程師的想法。 因此在 v1.2 的開發過程中,導入了敏捷開發程序 (Agile development process)[3], 但並非全盤採用整個開發程序,因為 Mozilla 的工程師、合作廠商散布在全球24個不同時區裡,沒辦法一次把不同時間、空間和文化的謀智人 (Mozillian) 聚集在一起跑敏捷開發程序。為了解決這個難題,讓整個開發過程更為彈性,因此我們採用一種混和 (Hybrid) 的開發、測試方式, 降低謀智人對開發程序轉換的痛苦。

以下為開發、測試 Firefox OS 所採用的程序、方法,
1. 常規會議 (Regular Meeting)
– 在敏捷開發過程中,因為變動是非常迅速的;為了要讓大家能在短時間抓住開發的方向,通常會有以下的常規會議,Kick off meeting, Standup meeting[4], Weekly meeting, Triage meeting 和 Retrospective meeting。

2. 專案需求以及規格的討論 (Requirements/Specification discussion)
– 我們利用 Work week 方式,增進了溝通的效率;以及利用此機會協調專案所需的資訊。

3. PRD/HLD/UX 文件 (PRD/HLD/UX document creation)
– 文檔!? 因為開發的週期即為短暫,任何的文檔通常是能精簡就精簡;但是該有的還是要有,像是 UX[5] 文件;而主要產品的需求被記錄在一份備忘錄 (Backlog) 裡,所有討論過程都會利用以下工具記載,並同步所有人的資訊。
( i ) MoPad [6]
( ii) Trello [7]
(iii) Pivotal Tracker [8]

4. 時間估計 (Effort estimation)
– 每個版本被規劃成4個 sprint 開發、測試;開發測試前,會利用 Planning Poker [9] 來估計每一項任務的所需時間。

5. 測試計畫 (Test plan)
– 測試計畫的提交通常在我們開發過程會被省略,因為在敏捷開發過程在短時間有太多的變動,導致測試計畫並不是那麼的準確、可參考。相對的,我們會產出一些縮小版測試計畫 Mini test plan,規劃每個 Sprint 需要達到的目標。

6. 產出測試用例 (Test case creation)
– 測試用例的產出是 QA 很重要的工作, QA 所有的測試用例都在 Mozilla MozTrap[10] 上,歡迎大家隨時上去參觀。

7. 審查測試用例 (Test case review)
– 測試用例準備好之後,會進入審查的程序,但因為跨時區工作的關係,大部分的程序會透過電子郵件或是視訊會議完成。

8. 執行測試 (Run testing)
– 因為每個 Sprint 的測試時間通常只有一週,所以我們捨棄了 Waterfall 的測試方式 (Stage-> Alpha->Beta-> -> Production) 。把測試分為 1~N run ,第一 run 會注重在軟體的功能性以及標準 (Criteria) 有沒有達到,第二 Run 以後會注重整合測試 (Integration testing) 的結果。

9. 臭蟲的提交、解決以及驗證 (Bug submission, solving, and verifying)
– 這過程是所有軟體開發必經之路;在 Mozilla ,我們利用了 Bugzilla[11] 記錄開發及測試時所遇到的問題、臭蟲 (Bug) 。

10. 代碼/測試用例維護 (Code/Test case maintenance)
– QA 通常會在測試結束後,檢查所創建的測試用例是符合產品需求,以及挑選適合自動化 (Automation test) 的測試用例。

目前Firefox OS v1.2 版進入 Code complete 階段 (9/15),不如就用這活生生的例子跟讀者解釋整個測試週期!在時間上,一個將要釋出的版本 (Release Build) 通常會歷經4週的策劃、討論,8週的開發、測試,時間表如下:

 v1-2_test_schedule

圖二、測試計畫表

如 上圖表,在開發初期,為了讓產品開發更順利, Mozilla 利用 work week 來討論產品需求以及標準,取得不同文化的謀智人對產品開發的共識;通常這時候謀智台北辦公室,根本像座空城,世界有多遼闊,謀智人就跑多遠,這是 一場很棒的知識及文化盛宴,有興趣的讀者歡迎搜尋 “Mozilla Workweek” 。 Work week 結束之後,通常就是Manager  、Developer 和 QA 努力發想,如何設計、測試、開發產品的階段;當取得大家的共識後,就是第一個 Sprint 開始啟程的時候。

在每一個 Sprint 的初期, QA 必須確保所有開發需求的內容以及完整性,不明確的內容,必須盡可能的與 Developer 或是 UX Designer 討論,而且要能提出開發的風險以及可能遭遇的問題,因為時間不能重來,錯誤的決策很容易影響到往後產品的釋出。當有明確的設計規格和需求後, QA 就會開始創造測試用例,測試用例的好壞和適用性通常取決於 QA 對產品以及相關知識的熟悉度;所以 Mozilla 的 QA 都像個活字典,隨時都準備好 讓人詢問相關產品規格、內容。通常在開發的過程中, QA 會保留半天來審查竭盡腦汁想出的測試用例;審查的過程,可以透過不同謀智人的觀點,快速的找出自己的盲點,加以改善測試用例的品質。開始運行測試之前, QA 必須要能針對測試的範圍、層面、平台、資源、時間等,組合出一個適合的測試策略讓其他的成員審 查。從上圖可以看出, V1.2 版的測試策略,主要由下列方法組成,冒煙測試 (Smoke Test) 、驗收測試 (Release Acceptance Test) 、整合測試 (Integration test) 、完整的運行測試 (Full run test) 和回歸測試 (Regression test) 。

一切就緒後,相關的測試就會如火如荼的展開,通常可以在 MozTrap 和 Bugzilla 上輕易的看出目前的測試狀態,兩個系統的效能也跟隨著 QA 的工作量成反比,就如同 Github 的提交量 (commit) 和 Developer 的工作量成正比的道理是類似的!

歷經幾回合的測試後,最終QA會提交一份測試報告給所有的利益相觀者 (Stakeholder) ,分析找到的問題以及軟體的品質,並提出相關風險評估。

就這樣沒了嗎? 怎麼可能!!!
最後一關,是對測試用例的分析,QA 會開始從手動測試中挑選適合做自動化測試 (Automation test) 的用例,並且整理測試用例。

這下應該真的沒了吧?!
不不不~在敏捷開發過程中,還有一個重要的一環-“回顧會議 (Retrospective meeting) ”,會議中會針對每一個 Sprint,做的對、做得好的項目提出來討論、表揚,該反省、檢討的事項會用備忘錄 (Backlog) 記載,並 提出改善方案,在下一次的回顧會議中,會拿出備忘錄來檢視是否改善。

以上,通常就是一個 Sprint 的運作過程。讀者可能會感到疑惑,採用以上敏捷測試的過程跟傳統測試流程有什麼大不同呢? 最明顯之處莫過於,我們把測試點提早,需求切割到最小,很多問題通常能在早期被發現,及早被解決;而不像傳統開發過程,整個專案都跑一半了才發現一堆漏洞、問題,想要分配人力解決,又發現所需的資源不足,陷入兩難的局面,造就無限期加班、無限期延長專案釋出。

目前 v1.2 版還算是敏捷測試的磨合期,一定會有讀者覺得美中不足的地方, Mozilla QA 正在竭盡可能的讓這一切變得更美好,相信 QA 會在 v1.3 的測試流程能有所突破。也礙於版面,沒能跟讀者分享太多細節,需要任何訊息嗎? 歡迎隨時跟我們聯絡,竭誠的歡迎您!

Mozilla Taiwan – “Doing good is part of our code”!

參考文獻:
[1] http://en.wikipedia.org/wiki/Waterfall_process
[2] http://tomfishburne.com/2010/04/the-new-product-waterfall.html
[3] http://en.wikipedia.org/wiki/Agile_software_development
[4] http://en.wikipedia.org/wiki/Stand-up_meeting
[5] http://en.wikipedia.org/wiki/User_experience_design
[6] https://etherpad.mozilla.org/
[7] https://trello.com/
[8] http://www.pivotaltracker.com/
[9] http://msdn.microsoft.com/zh-tw/library/hh765979.ASPX
[10] https://moztrap.mozilla.org
[11] http://www.bugzilla.org/

您可能也會喜歡

目前找不到相關文章

對此文章發表回應

你的電子郵件位址並不會被公開。 必要欄位標記為 *