一般來說在專案開始開發前，開發團隊會開一個設計審查會議(Design Review)

跟團隊確認接下來的開發週期，RD會開發什麼功能，以及怎麼開發的細節

透過跟團隊內不同角色的溝通與確認，在開始做事之前取得大家的共識與審核。

那測試團隊也是一樣，在設計審查結束後，QA也會針對開發功能與細節做確認

並開一個測試計畫審核會議（Test Plan Review）來跟團隊說明QA的測試計畫。

測試策略(Test Strategy)與測試計畫(Test Plan)

而在擬定測試計畫前，會有個設定測試策略的環節，目的是要確保你在做最重要的事。

主要包含以下三點：

• 測什麼？

  測什麼就是QA要去評估本次的測試範圍，明確定出你需要測試的東西。

• 怎麼測？

  怎麼測就是QA本次打算用哪些測試種類與工具環境來執行這次的測試。

• 可以測多久？

  可以測多久很白話，就是你有多少時間可以做測試。

有句話是這麼說的：「一個月有一個月的測法，一週有一週的測法。」

背後隱含一個重要的意涵：測試優先度的制定(Test Priority)

這個我們留到後面的章節再多加著墨。

與測試策略的大方向不同，測試計畫需要把測試細項在審查會議中提出

測試計畫目的是跟團隊說：「這個新上線的功能，交給我們QA來把關就沒問題了。」

而QA需要在會議中，把這次改動會影響到的地方說出來，並要怎麼去測試的細節提出

所以自然會包含我們上篇提到的使用者場景跟各式不同的測試種類、細節與工具方法

測試種類簡單幾個：功能測試、性能測試、邊界測試、整合測試、安全測試等等。

不同的產品測試也會有相對應適合的測試工具與測試方法，要對症下藥。

審查會議還有個最重要的目的是：「得到團隊成員的反饋」

許多產品年代久遠的設計邏輯跟改動程式可能產生的副作用，不是每個人都能非常了解

這時候就需要集眾人之力量，把高風險的邏輯改動提出來，確保測試團隊有考慮到。

每次Test Plan Review都是QA練功的機會

不同背景的團隊成員都會提出不同面向的問題跟建議，可以從中學習到很多觀點

比如說前端工程師會跟你說表單功能，字元上限最多只能放255個字元，要測。

設計師會跟你說我們所有的Tooltip都是on hover popup，要測。

PM會跟你說License過期90天之後就要Expire，既有功能都要關掉，要測。

下次你再設計測試計畫的時候，就會對這些曾經被提出過的細節有印象。

隨著測試經驗越來越多，你也會慢慢知道什麼地方容易出問題，

觀察事情的角度跟全面性也會越來越完整，這也是QA工程師有趣的地方。

Bonus練習題：試著理解並分解測試目標

最後我們來舉個比較實際的例子，來實戰演練如何制定你的測試策略與測試計畫。

今天你的產品是個雲端記帳服務，已上線功能有支援台幣與美金記帳

雲端主要記帳功能假設簡單有：

• 支援網頁與iOS App同步更新
• 資產一覽表
• 每日收支明細

這次的新功能是打算加入比特幣的幣種支援，身為一個QA你需要考量的點會有那些？

測試策略簡單範例

測什麼：

• 增加比特幣支援幣種
• 台幣美金記帳沒有更動，優先度可以放後面一點。
• 網頁+App都要能夠正常顯示並支援同步更新

怎麼測：

• 網頁要準備有支援的瀏覽器跟OS環境
• App要準備不同版本的虛擬機環境與實體測試機
• 著重在比特幣記帳的功能面測試，以及資產一覽表的總資產數值的邊界測試

可以測多久：

• 一週可以測完新功能針對比特幣的幣種支援
• 但如果要確保台幣美金的記帳功能也都沒問題，可能還需要多一週的時間。

測試計畫範例...就當回家作業（誤）

下一篇開始來聊聊各種不同琳瑯滿目的測試種類。