小明與老王的日常:學會做這4件事,讓你的產品提前上線(4)

6 評論 7378 瀏覽 65 收藏 11 分鐘

《老王與小明的日?!废盗旭R上就要收尾了。而這篇文章,會介紹如何進行產品測試,同時也是本系列的一個總結。

太多的產品新人,甚至于工作一兩年的產品汪,在開發階段往往出現很多對接問題,影響上線進度。在此,我將程序開發階段總結為一下4個階段,并以故事的形式,分流程介紹我們該如何與開發對接。因內容較多,且需要與實際工作結合進行考慮,所以建議大家收藏下來,慢慢看。

下圖為此系列內容的大綱:

(此系列內容的大綱)

今天我們說說第4部分,產品測試。如果沒有看過前三篇文章的同學, 請點擊下面的傳送門:

《小明與老王的日常:學會做這4件事,讓你的產品提前上線(1)》

《小明與老王的日常:學會做這4件事,讓你的產品提前上線(2)》

《小明與老王的日常:學會做這4件事,讓你的產品提前上線(3)》

產品測試在很多公司,都會有專門的部門進行負責。而此篇文章主要介紹的是在沒有測試人員的情況下,產品經理如何兼任測試崗位,進行產品測試。文章主要包含三部分:

確定測試介入時間

在瀑布流開發過程中,通常在開發完成后才進行產品測試。這時候,測試人員拿到的版本通常是經過程序猿初步測試的版本。

  • 優勢:開發與測試的時間節點可控,且測試前有充足的時間進行測試準備工作。
  • 劣勢:劣勢非常明顯,會大大延長了產品上線時間。

而在現階段大部門的互聯網公司中,大家通常將開發的功能按模塊劃分好,并確定模塊的開發順序(具體可以查看第2篇文章)。當完成某個模塊的開發,便對該模塊進行單元測試。這時候測試人員拿到的版本通常是一個產品雛形。

優勢

  • 可以將減少一部分產品測試的時間。
  • 時刻跟進產品開發方向,避免程序猿開發出來的東西不是原先想要的產品。

缺點

  • 對程序猿能力要求較高,需要確保每個模塊開發出來的主流程必須是可用于測試的。
  • 增加了產品在開發階段的工作量。(如果公司沒有安排測試人員的話)

以上的兩種方式,我更傾向于第2種,并且在自己日常工作中,也采用第2種方式。可大大縮短項目的開發周期。每個模塊測試一遍,上線前再完整測試一遍,基本上不會出現太大問題。當然了,每種方式均不是完美的,這需要產品經理根據項目的不同,進行選擇。

測試前的準備工作

在確定了介入時間之后,接下來我們就要做測試前的準備,測試前的需要準備的東西通常包括:測試用例、測試人員、測試環境(系統、瀏覽器等)

  • 測試用例:測試人員為測試某一個功能是否滿足既定的要求,而編寫的一組測試輸入、執行與結果展現的標準文檔。目的是為了讓測試更加標準。通常情況下,一份詳細的PRD文檔也可以用來做測試用例,不需要在編寫測試用例上花費時間。
  • 測試人員:大公司都有專門的測試部門用來進行產品測試工作。小公司的大多數都交給產品經理或產品助理來完成,在這個時候,我們就要協調好測試人員,保證在測試階段,有專人負責。當然在產品經理親自上陣的時候,也需要考慮到自己的手頭工作,做好工作安排。
  • 測試環境:App測試的環境主要是各種手機系統與系統版本,web主要是各種瀏覽器。Pc軟件主要是操作系統。所以在進行測試前,需要將這些必要的環境搭建好

測試準備階段,根據產品的性質不同,可能還需要準備不同身份的測試賬號、材料(閱卷系統的答題卡)等物品。在此推薦大家在準備階段,列舉一個測試準備清單,并在測試前反復確認,保證測試工作的正常進行。

隨手畫的一個清單,不一定適用于大家所有的項目,僅提供參考。

測試報告產出

在測試過程中,我們需要將發現的bug記錄在測試報告中,而為了方便程序猿們的查看,我們的測試報告需要包含以下幾個要素:

  • 嚴重程度:嚴重主要描述bug可能造成的影響,我們通常將嚴重程度分為4級。1為最強、4為最弱。具體的劃分1為主流程bug;2為輔助流程bug;3為交互bug;4為樣式bug。方便項目經理安排bug修復的任務。
  • 修改優先級:優先級主要是為了方便指導程序猿的bug修改順序。通常我們將bug修改為3級。1代表緊急bug,需要立即修改。2代表需要上線前修改完成的bug。3代表可放在上線后進行修改的bug。
  • Bug內容:主要用來描述產品bug的內容,例如“點擊登錄按鈕無反應”。問題不宜長篇大論,突出重點就可以。
  • 重現步驟:標注好問題重現步驟,方便程序猿快速找出問題的原因。對上述的bug內容我們可以這樣描述“將瀏覽器內核設置為為ie9,進行賬號登錄,點擊登錄按鈕無反應”。
  • 需求描述:主要描述bug需要修改成什么樣子,方便程序猿制定修改方案。例如“登錄功能需要兼容ie9內核”。結果描述要有具體的結果,不宜模棱兩可。

注:在一部分情況下,我們會將bug內容、重現步驟、結果描述寫在一起,統一叫做bug內容。

修改人、修改情況、備注說明

明確bug的修改人,修改情況與備注,可方便我們對bug修改過程進行跟蹤。通常修改人由項目經理進行分配。修改情況與備注由程序猿記性填寫,最終需要測試人員進行確認。

當1份報告需要多個用戶同時查看,excel無法實現多用戶同時在線編輯的弊端就非常明顯了。這時候如果有一款專門的協同開發工具是不是更好?

關于產品測試階段,就介紹這么多了,下面主要會將《老王與小明的日常》這個系列做一個總結。

系列總結

老規矩,先把圖亮出來,下面這張圖就是此系列文章的大綱:

下面這些都是此系列文章的重點總結,有疑問的小伙伴可以參考對應的文章進行查看。

需求傳達階段

  • 傳達項目背景,讓程序猿認為他們是在做一款改變世界的產品。
  • 有節奏的介紹需求,當然了,這里的節奏不是“啪啪啪”的節奏,而是要分清介紹的主次
  • 確定關鍵性目標,讓程序猿對開發結果有個明確的目標。

制定開發進度與關鍵節點階段

  • 給足程序猿評估項目周期的時間,目的是讓程序猿充分了解需求,需求了解后,評估時間自然而然就出來了。
  • 適當的接受程序猿的建議,需要砍需求的時候,不要猶豫。
  • 確定開發順序,為后期開發跟進與測試打好基礎。
  • 明確關鍵時間節點,為項目管理提供依據。

跟進開發階段

  • 模塊開發前,做好相應模塊的需求變更與需求確認。
  • 明確站立會與周例會的工作職責。
  • 做好支持與協調工作,為開發擺平一切困難

產品測試階段

  • 確定好測試的介入時間
  • 用清單的形式,做好測試準備工作
  • 提交切實可用的測試報告。

感謝

一周多的時間將此系列寫完,時間確實有點緊。導致了每篇文章中都有很多地方表達不是很清楚,所以在此非常感謝小伙伴們的支持。希望這4篇文章對您的工作有一定的幫助。

相關閱讀

《小明與老王的日常:學會做這4件事,讓你的產品提前上線(1)》

《小明與老王的日常:學會做這4件事,讓你的產品提前上線(2)》

小明與老王的日常:學會做這4件事,讓你的產品提前上線(3)

 

作者:李英杰,二一教育高級產品經理,主要負責題庫類產品的規劃與運營工作。

本文由 @李英杰 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Pexels,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 寫的很好,對于新人很受用,感謝了老王!

    來自上海 回復
  2. 又見到你了老王

    回復
    1. 哈哈,躲這么久,還是被你蹲到了

      回復
  3. 有希望一起學習,一起進步的小伙伴,可以加老王微信liyingjie153804

    來自廣東 回復
    1. 就問老王是男是女!?!···

      來自江蘇 回復
    2. 你猜…

      回復