擁抱高效、擁抱 Bugtags 之來自用戶的聲音（五）

Bugtags使用心得（創業公司場景篇）

——成都嘿嘿科技有限公司 做者：小花

1、產品定義

關於手機客戶端產品（APP）的 bug 提交、監測及管理且具備團隊協做性質的系統。

2、使用環境

公司：初期創業公司，團隊 10 人之內，全體使用。
產品：初期，穩步迭代中。

3、測試類產品分析

從進入互聯網行業中一直從事與 APP 測試、運營相關的工做，由於初創公司沒有測試團隊，都是全民測試，因此從 14 年至今也積累了一些非專業的測試經驗，也使用過一些軟件來進行測試工做的管理與團隊協做。

目前市場上與 bug 與相關的產品或服務大體分爲兩大類：

1. bug 測試類-爲了進一步進行專業全面的深度測試

2. bug 管理監控類-爲了本身團隊進行測試工做體驗更便捷和科學

一、Bug 測試類：

關於 bug 測試類有大概分爲專業測試和分衆測試，好比 testin 和 fir.im。
因爲創業團隊的產品線和業務部門沒有已據規模的公司那樣多和規範，因此通常的創業公司沒有也養不起一個專業的測試團隊，不會設立測試部門，而一個新的產品或版本開發完成以後，又沒有比較多的種子用戶能夠幫助測試以達到收集更多樣本信息。
因此 bug 測試類產品主要解決的時創業公司沒法對本身的產品進行專業、大範圍的測試工做。
以下圖：

二、Bug 管理監控類類：

通常的對於 bug 管理的需求大概分爲三種：

1. 提交（使用產品的人主動提交併說明）；

2. 對 bug 進行管理（bug 狀態處理、任務指派、bug 說明等）；

3. 對 bug 進行監控（監控非主動提交狀況以外的 bug，崩潰、閃退等）；

至於 bug 的監測，一般會另外使用一個第三方的產品（大公司除外），好比友盟統計中的錯誤分析功能，bugly 等，暫不詳細描述。

四． Bugtags 使用場景分析

Bugtags 屬於 bug 管理類產品，解決的問題是打通全部測試環節，優化每一個環節，從而使整個流程更輕。

一、正常場景

我接觸過的大多數創業公司一般的測試工做是這樣展開的：

二、創業公司場景

在沒有測試團隊的狀況下，創業公司一般須要團隊的每一個人都參與到非專業的測試工做中來，包括產品、市場、運營、客服、以及他們身邊的朋友。當非測試與專業人員一同參加測試，隨時隨地心繫產品發現問題提交問題時，這是一件好事。
但是因爲非專業人員不懂得開發人員的工做屬性，當每一個人都把發現的問題丟給開發人員時，因爲缺乏梳理和明確的描述，會讓程序員耗費大量重複性的溝通時間和精力。
通常來講開發者面對一個 bug 一般須要如下四個問題來幫助本身進行判斷：

1. bug 描述是否清楚？（非程序員：一直閃退！ 程序員：你幹了什麼閃退？）

2. bug 可否復現？（非程序員：聊天閃退！程序員：我試了沒閃退啊！）

3. bug 出現前作了哪些操做？（非程序員：我真的閃退！ 程序員：我看看你怎麼操做引發閃退的？）

4. bug 是否有對應的記錄日誌？（非程序員：你看我就正常操做，真的閃退吧！ 程序員：我看了下代碼邏輯都沒問題，等我給你打個日誌你再操做一遍我看看問題出在哪！）
   整個流程大體以下圖：

三、遇到的問題

能夠看出正常流程會帶來如下三個問題：

1. 下降開發效率

   Bug 的提交一般須要口述或者演示給開發人員，再由開發人員記錄，下降了效率，給開發人員增長了一些沒必要要的工做。

2. 描述與提交 bug 的銜接不夠平滑

   即便人人均可以登陸 bug 管理系統自行提交，bug 的發現和提交一般會脫節或操做不便捷。我常常在隨意使用中忽然發現了一個 bug，我須要登陸系統提交以及對 bug 進行截圖輔助說明。那麼我會受到環境的影響，會須要進行截圖、編輯、上傳等動做，會有一些不便捷。

3. 操做步驟不易記憶與描述

   Bug 出現前的操做須要記憶。跟開發人員溝經過 bug 問題的人都瞭解，開發人員面對一個 bug 時，最關心兩點，可否復現和操做步驟，後者能幫助他們判斷問題出在哪和尋找邏輯上的錯誤。而非專業或不常常進行測試工做的人來講，好比團隊中的運營、市場、身邊朋友，他們一般是沒法清晰的口述 bug 出現以前的操做步驟。
   因此，尤爲在創業公司，每一個參與測試中或能夠爲測試貢獻一些力量的人，都有一個能夠提升效率、操做平滑、符合使用習慣的 bug 管理系統的需求。Bugtags 很好的知足了這一需求，簡單來講的話，Bugtags 解決和優化思路有點相似流行的「雲」，互聯互通。大體流程和原理以下圖：

五．Bugtags使用步驟

1. 在線截圖、編輯與描述問題，且崩潰會自動截圖發送。
   接入了 Bugtags 的 SDK，會出現一個懸浮小球。若是在使用過程當中發現了 bug 或問題，直接點擊小球，Bugtags 會自動截取當前屏幕圖片，而後進入編輯狀態，而後就可使用標籤編輯 bug 信息了，整個過程無需跨平臺，和二次編輯。

   在問題頁面直接點擊小球

   再點擊鉛筆，自動截圖進入編輯頁面

   自動截圖完畢

   點擊有問題的地方，直接在線編輯 bug

   bug 編輯完成，點擊小飛機圖標發送提交就搞定啦♪(^∇^*)

   bug 提交成功後會自動出如今後臺，程序員查看便可

   經過以上操做，大多數產品經理或者老闆，能夠隨時隨地向程序員、設計師反饋問題。

2. 自動生成設備與環境信息

3. 自動記錄用戶步驟和日誌

六．Bugtags 整體使用感覺

首先，簡單、便捷、專業，很好的解決了上面所列出來的問題：

1. 提升溝通和開發效率；
2. 流程平滑；
3. 自動記錄解決 bug 所需的環境與信息。

而後，由於這些優化，讓不少場景能夠融入到測試工做中，好比產品經理在家裏躺着給程序員反饋哪些細節須要調；好比客服小妹妹能夠和用戶溝經過程中及時反饋 bug。
這無疑是從場景出發設計出來的知足用戶需求的產品，聯通了數據，聯通了操做，聯通了場景，也聯通了需求。
好的產品老是給人一種「天然」的感受，彷佛也沒辦法生硬的讚美什麼。

七．給 Bugtags 一些建議

1.能夠接入或開發配套的監測用戶 bug 數據的產品。
2.集合全部接入 Bugtags SDK 的開發者，集中你們在開發中遇到的問題，創建一個有別於 Github 的垂直創業公司的輕開發社區。

​