如何為你的應用程式進行測試版測試

要進行測試版測試，首先決定你需要了解什麼，邀請一小群符合真實用戶特徵的人，給他們一個清楚的首項任務，並在固定的時間表上於一個地方收集意見。修正阻礙他們的問題，分輪擴大測試群組，並在你事先寫下的完成標準達到時結束測試版，而不是等到自己失去耐性為止。

測試版不是軟性推出，而是一個有起點、有終點，並且要回答一個問題的有結構實驗。

測試版的定位

驗證要回答的是問題是否值得解決；測試版則回答一個較窄的問題：這個版本的產品，能否在真實的情況下為真實的人解決問題？ 推出應該在這之後進行，前提是答案大致為是。

在邀請任何人之前，請先自行測試 — 如何在推出前測試你的應用程式 涵蓋了這部分。測試人員不應該是那個發現註冊功能壞了的人。

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

挑選兩至三個問題。計劃中的其他一切都由這些問題衍生。

虛構的例子： 一款為小型咖啡店設計的排班應用程式，設定了兩個目標：「經理能否在首次使用時，不靠協助就發佈一週的更表？」以及「員工在第二週會否自行打開應用程式？」

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

對於第一個產品，通常以封閉測試版搭配數輪測試是正確的做法。

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

最理想的測試人員現在就有這個問題，符合你的目標用戶，並且在測試期間有時間試用應用程式。以下是尋找他們的途徑：

• 你的候補名單或電郵名單 — 參閱如何在推出前建立受眾。
• 你在驗證階段訪問過的人。
• 目標用戶聚集的小眾社群，但宣傳時要遵守其規則。
• 直接邀請你人脈中符合特徵的人。

問幾條篩選問題，以便挑選出多元化的組合：他們的職位、現時如何解決這個問題、會用什麼裝置，以及這個問題多久出現一次。邀請回答符合你目標用戶的人，除非他們正好是目標用戶，否則避免讓測試版充斥著其他創辦人。

邀請範本

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

誠實地說明所需的時間投入。知道自己報名了什麼的人，會提供更好的意見。

第 4 步：準備測試用的資料包

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

• 歡迎訊息，包括連結、登入方法、首項要嘗試的任務，以及如何回報問題。
• 已知問題清單，免得測試人員把同一件事重複回報十次。
• 單一的意見回饋渠道。 一份表格、一個共享的聊天群組或一個電郵地址，只用一個，而不是五個。
• 錯誤報告範本。 詢問他們做了什麼、預期會發生什麼、實際發生了什麼、用的裝置及瀏覽器，以及一張截圖。如何寫出好的錯誤報告 中有一個可以分享的版本。
• 基本的分析或日誌，讓你不用依靠記憶，也能看見發生過什麼。
• 清楚的資料期望。 如果測試期間資料可能會被重設，要告訴測試人員；也不要要求他們把敏感資料放進未完成的應用程式中。
• 條款與私隱基本資料。 一份簡短的測試協議及私隱說明；如果你處理個人資料，請查閱當地規定或諮詢專業人士。

第 5 步：分輪進行

分輪進行，可以讓你在更多人遇到問題之前先修正它們。

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

第 6 步：按節奏收集意見

沒有結構的「有什麼意見嗎？」通常只會得到含糊的回覆。改為使用簡短、定期的跟進問卷：

每週跟進（虛構的例子問題）

1. 你這星期用 [產品] 做了什麼？
2. 有什麼地方令你感到沮喪或困惑？
3. 有沒有缺少了什麼，令你無法完成某項任務？
4. 如果你日後不能再使用它，你會有什麼感覺？（非常失望／有點失望／毫不在意）
5. 還有其他意見嗎？

把人們所說的，與他們實際的行為結合起來看。一個說很好用、卻從不登入的人，同樣在告訴你一些事情。

第 7 步：為收到的意見分類

把所有意見放入同一份清單，並每週分類一次。

測試期間應避免加入大型新功能。每加入一項新功能，都會令你更難判斷核心產品是否正常運作。

第 8 步：形成回饋閉環

當測試人員看到他們的意見被採納，他們會更願意繼續提供意見。

• 每一輪結束後發送簡短的更新日誌：「你回報的 X 已修正。」
• 當某人的回報促成了修正，請私下以其姓名向他致謝。
• 測試版結束時告知測試人員，並說明他們的資料與帳戶會如何處理，以及他們的創始優惠是什麼。

第 9 步：判斷是否已準備好

在測試版開始前寫下完成標準，並在結束時誠實地逐項檢查。以下是一個範本：

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

如果大部分項目都已達標，就進入入門體驗的打磨，並準備公開推出。如果回頭使用的人很少，那是產品的問題，而不只是錯誤清單的問題；在推出之前，應回頭重新進行訪談。

在 Mythex 進行測試版

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

• 第一輪的預覽連結。 Share 按鈕會為你的即時預覽建立一個連結，沒有 Mythex 帳戶的人也可以使用，因此早期測試人員可以在你發佈之前試用未完成的功能。每個群組建立一個連結，完成後便刪除。預覽文件 會說明連結如何喚醒專案及使用點數。
• 較長的測試輪次使用已發佈的版本。 已發佈的應用程式會運行在它自己的網址上，適合讓測試人員在數週內持續使用。
• 每輪開始前進行 App Testing。 在對話中輸入 /test，agent 會在你的預覽中操作，並回報失效的流程；在邀請任何人之前，這是很有用的檢查（App Testing 文件）。
• 檢查點。 如果測試期間某項修正令其他功能出錯，可以還原至較早的檢查點。

把測試人員的錯誤報告直接貼入對話，請 agent 重現並修正，然後在修正上線後告知測試人員。

常見問題