如何為你的 App 進行測試版測試

要進行測試版測試，請先決定你需要了解什麼，邀請一小群符合真實使用者特徵的人，給他們一個清楚的第一項任務，並在固定的時程中將回饋集中收集在同一個地方。修正阻礙他們的問題，分輪次逐步擴大群組，並在你事先寫下的結束標準達成時結束測試——而不是等到你失去耐心。

測試版不是軟性上市。它是一項有開始、有結束、並且要回答一個問題的結構化實驗。

測試版適合在哪個階段

驗證要回答的是：這個問題值不值得解決。測試版要回答的則是更窄的問題：這個版本的產品，能否在真實情境中為真實的人解決這個問題？正式上市則是在答案大致為肯定之後才進行。

在邀請任何人之前，先自己測試——如何在上線前測試你的 App說明了做法。測試人員不應該是那個發現註冊功能壞掉的人。

步驟 1：寫下測試版必須回答的問題

挑出兩到三個問題。整份計畫都應圍繞它們展開。

虛構範例： 一款為小型咖啡店設計的班表排班 App，設定了兩個目標：「經理能否在第一次使用時，不需協助就發布一週的班表？」以及「員工在第二週是否會自己打開 App？」

步驟 2：選擇測試版的類型

對於第一個產品，通常最好的做法是進行幾輪的封閉式測試版。

步驟 3：招募合適的測試人員

最好的測試人員目前就有這個問題、符合你的目標使用者，並且在測試期間有時間試用 App。可以從以下地方找到他們：

• 你的候補名單或電子郵件名單——請參閱如何在上市前建立受眾。
• 你在驗證期間訪談過的人。
• 目標使用者聚集的小眾社群，但請遵守社群關於推廣的規範。
• 直接邀請你人脈中符合條件的人。

問幾個篩選問題，好讓你挑選出多元的組合：他們的職位、目前如何解決這個問題、會使用哪種裝置，以及這個問題多常出現。邀請回答符合目標使用者的人，除非他們本身就是目標使用者，否則避免讓創辦人同行佔滿測試名額。

邀請範本

嗨 [名字]——你註冊時提到過 [問題]。我正在開放一個小型的私人測試版 [產品]，它能 [成果]。測試時間為 [開始日期] 到 [結束日期]。我希望測試人員每週至少用它完成一次 [真實任務]，並在每週五回覆一份簡短的進度回報。作為回報，你在測試期間可免費使用，並享有 [創始價格／延長的免費期]。有興趣嗎？

請誠實說明所需的時間投入。知道自己報名了什麼的人，會給出更好的回饋。

步驟 4：準備測試工具包

在寄出第一份邀請之前，請先準備好以下內容：

• 歡迎訊息，包含連結、登入方式、建議的第一項任務，以及如何回報問題。
• 已知問題清單，避免測試人員把同一件事回報十次。
• 單一回饋管道。 一份表單、一個共享聊天群組或一個電子郵件信箱——只用一個地方，而不是五個。
• 錯誤回報範本。 請他們說明做了什麼、預期什麼、實際發生了什麼、使用的裝置與瀏覽器，以及一張截圖。如何撰寫良好的錯誤回報提供了可分享的版本。
• 基本分析或紀錄，讓你不必依賴記憶，也能看清楚發生了什麼事。
• 關於資料的明確說明。 如果測試期間資料可能被重設，請告訴測試人員；不要要求他們把敏感資訊放進尚未完成的 App 中。
• 條款與隱私基本說明。 一份簡短的測試協議與隱私聲明；如果你處理個人資料，請確認當地法規或諮詢專業人士。

步驟 5：分輪次進行

分輪次進行，能讓你在更多人遇到問題之前先修正。

在第 1 輪中，請兩到三位測試人員在第一次使用 App 時共享他們的螢幕。保持安靜，觀察他們在哪裡猶豫。這往往是整個測試版中最有價值的一個小時。

步驟 6：依固定節奏收集回饋

沒有結構的「有任何回饋嗎？」訊息，只會得到模糊的答案。改用簡短、定期的回報來取代：

每週回報（虛構的範例問題）

1. 你這週用 [產品] 做了什麼？
2. 有哪些地方讓你覺得挫折或困惑？
3. 有沒有缺少什麼，導致你無法完成某項任務？
4. 如果你再也無法使用它，你的感受會如何？（非常失望／有點失望／完全不在意）
5. 還有其他想法嗎？

把人們所說的與他們實際做的結合起來看。一個說它很棒、卻從不登入的人，也在告訴你某些事情。

步驟 7：分類處理收到的回饋

把所有回饋放進同一份清單中，並每週分類整理。

測試期間請克制加入大型功能的衝動。每新增一項功能，都會讓人更難判斷核心產品是否正常運作。

步驟 8：讓回饋形成閉環

當測試人員看到自己的回饋被採用，他們會持續提供回饋。

• 每一輪結束後寄出簡短的更新日誌：「你回報的 X 已修正。」
• 當某位測試人員的回報促成了修正，請私下、以名字向他們致謝。
• 測試結束時告訴測試人員：測試結束後他們的資料與帳號會如何處理，以及他們的創始優惠是什麼。

步驟 9：判斷是否準備就緒

在測試開始前寫下結束標準，並在結束時誠實地逐項檢查。範本如下：

• 沒有已知的阻礙或資料遺失錯誤
• 多數新測試人員能在沒有協助的情況下完成核心任務
• 有相當比例的測試人員在後幾週自行回來使用
• 最主要的困惑點已修正並重新測試
• 註冊、重設密碼，以及任何付款流程，端到端都能正常運作
• 你能用測試人員的語言，清楚說明這個產品是為誰而做的

如果大部分的方框都已打勾，就進入上手流程的打磨，並準備正式上市。如果回訪率很低，那是產品問題，而不是錯誤清單的問題——在上市前，請回到訪談中重新檢視。

使用 Mythex 進行測試版

如果你使用 Mythex 建置，有幾項功能很適合套用在測試版中：

• 第 1 輪使用預覽連結。 Share 按鈕會建立一個指向你即時預覽的連結，不需要 Mythex 帳號即可開啟，讓早期測試人員能在你發布之前試用未完成的作品。每個群組建立一個連結，結束後就刪除它——預覽文件說明了連結如何喚醒專案並使用點數。
• 較長的輪次使用發布版本。 已發布的 App 會在自己的位址上運行，適合讓測試人員連續使用數週。
• 每一輪之前進行 App 測試。 在對話中輸入 /test，Agent 會在你的預覽中操作，並回報壞掉的流程，這在邀請任何人之前是很好的檢查（App 測試文件）。
• 檢查點。 如果測試期間的修正導致其他功能壞掉，可以回復到較早的檢查點。

把測試人員的錯誤回報直接貼到對話中，請 Agent 重現並修正，然後告訴測試人員修正已經上線。

常見問題