商業錯誤回報撰寫
根據您的筆記撰寫、附重現步驟的清楚錯誤回報
價格起 US$12
成果範例
標準版方案範例
Technical specification: booking website for a yoga studio
1. Project goals
- Let clients see the timetable and book a class in under one minute, from a phone.
- Sell class passes and memberships online.
- Cut the time staff spend on bookings from about 10 hours a week to under 2.
Success measures (3 months after launch): 70% of bookings made online; no-shows below 10%.
2. Users
| Role | What they need |
|---|---|
| Visitor | See classes, prices and teachers; buy a first-class trial |
| Client | Book and cancel classes, see remaining passes, join a waitlist |
| Teacher | See their own classes and the list of booked clients |
| Admin | Manage timetable, prices, passes, teachers and refunds |
3. Pages and screens
- Home: next classes today, trial offer, studio address.
- Timetable: week view, filters by class type, level, teacher and room.
- Class page: description, teacher, length, places left, Book button.
- Prices: single class, 5- and 10-class passes, monthly membership.
- Teachers: list and individual profiles.
- Account: upcoming bookings, history, passes, payment methods.
- Admin panel: timetable editor, client list, sales report.
4. Key features
4.1 Booking
- A client can book if they have a valid pass or pay for a single class.
- Class capacity is set per room (Room A: 18, Room B: 10).
- When a class is full, the client can join a waitlist; if a place opens, the first person in line gets it and receives an email and text message.
4.2 Cancellation
- Free cancellation up to 12 hours before class; the pass credit returns.
- Later cancellation or a no-show uses up the credit.
4.3 Payments
- Card payments through a payment provider chosen by the studio.
- Passes expire: 5-class after 2 months, 10-class after 3 months.
4.4 Notifications
- Booking confirmation, reminder 3 hours before class, waitlist updates.
5. Non-functional requirements
- Mobile-first; pages load in under 2 seconds on 4G.
- Works in the two latest versions of major browsers.
- Personal data stored in line with local data protection law.
6. Open questions
| # | Question | Who decides |
|---|---|---|
| 1 | Do teachers mark attendance in the app, or does the front desk? | Studio owner |
| 2 | Is a 2-week trial pass needed in addition to a single trial class? | Studio owner |
| 3 | Should the timetable be embedded on the current website or replace it? | Owner + developer |
| 4 | Which payment provider and text-message service are preferred? | Owner |
Client: Lotus Lane Yoga, a studio with 2 rooms, 9 teachers and about 60 classes a week. Today bookings go through direct messages and a paper sign-up sheet. Standard package: specification up to 10 pages. Excerpt below.
客戶與所有細節皆為虛構。
關於此服務
版本發布往往壞在平淡無奇的地方：小尺寸 iPhone 上的結帳頁、接受空白電子郵件的表單、太快失效的密碼重設連結。我們根據您網站或 App 的描述、畫面或使用流程撰寫測試案例：每個案例都有步驟、測試資料與預期結果，並分成冒煙測試、迴歸檢查與邊界情況。您團隊中的任何人都可以在發布前執行這份清單，並以一致的方式回報錯誤。
包含內容
- 您會收到什麼附編號、步驟、測試資料與預期結果的測試案例，依功能與優先順序分組，另有發布前檢查清單與錯誤回報範本，格式化文字可貼進試算表或測試管理工具。
- 冒煙測試每次都必須通過的幾項檢查
- 功能測試案例步驟、資料與預期結果
- 邊界情況空欄位、超長文字、網路不佳、輸入錯誤
- 裝置涵蓋範圍哪些檢查要在哪些瀏覽器重複
- 錯誤回報範本讓每個錯誤都附上相同的細節
服務流程
- 1需求說明您分享畫面、流程與裝置
- 2撰寫我們依功能與優先順序撰寫案例
- 3檢查清單您會收到可直接執行的案例
需要您提供的資料
網站或 App 的連結（若已公開）、畫面與流程的截圖或描述、使用者所用的裝置與瀏覽器，以及這次發布改變了什麼。
我們會詢問您：
- 這是網站、網頁應用程式還是行動 App？
- 哪些功能或流程必須測試？
- 哪些裝置和瀏覽器最重要？
- 由誰來執行測試？
比較方案
付款保障
下單時付款，但只有在驗收成果後，款項才會撥付。
- 固定價格付款後，方案價格不會變動。
- 款項先行保留付款時，金額只會先保留，在您驗收後才會撥付給服務。
- 交付前檢查每份成果在交到您手上之前都會經過品質檢查，您也可以在驗收前於訂單頁面查看成果。
- 免費修改在需求說明範圍內，可依方案允許的次數提出修改。
- 3 天後自動驗收若您在交付後 3 天內未驗收也未提出修改，成果將自動驗收。若您在交付後於訂單聊天室留言，訂單會暫停自動驗收；我們回覆後，可能會重新起算 3 天，並會在聊天室中告知。
- 重新製作或全額退款若成果不符合您的需求說明且修改後仍未改善，或製作時間超過交付期限的兩倍，請在訂單聊天室留言：我們將重新製作，或全額退還款項。
常見問題
你們會自己測試網站嗎？
不會。我們撰寫測試案例與檢查清單；由您的團隊或測試人員執行並記錄結果。
可以匯入 TestRail 或 Qase 嗎？
可以。請在需求說明中要求 CSV 風格的表格，欄位會符合一般的匯入格式。
你們會寫測試程式碼，例如 Playwright 或 Selenium 腳本嗎？
不會，這些是手動測試案例。它們通常是團隊撰寫測試程式碼之前的第一步。
沒有找到您要的答案？
