產(chǎn)品小白進行產(chǎn)品驗收,從這些方面入手
第一次做產(chǎn)品驗收,該從何下手?文章分析了產(chǎn)品驗收過程中所需的準備步驟及注意事項,一起來看看吧。
開發(fā)人員完成開發(fā)后,不僅需要測試同學對產(chǎn)品進行測試,產(chǎn)品經(jīng)理也需要對其進行驗收。開發(fā)完的產(chǎn)品不可避免的會與產(chǎn)品定義出現(xiàn)偏差,因為程序員爸爸們有的時候不會特別仔細的看文檔,或者會偷偷的改需求,或者失戀了很傷心代碼隨便寫寫算了,這個時候驗收工作就顯得尤為重要了。
一、產(chǎn)品驗收是什么
那么產(chǎn)品驗收到底是啥?產(chǎn)品驗收就是對產(chǎn)品進行檢驗,看產(chǎn)品與需求是否存在偏差。對著你的產(chǎn)品點點點,發(fā)現(xiàn)它的問題,然后提給測試或者直接提給開發(fā)人員,讓他們改改改,這就是全部了。
產(chǎn)品驗收的目標在于保證產(chǎn)品質(zhì)量,達到設計預期。
跟測試不同的是,我們在驗收時不僅需要驗收產(chǎn)品功能,同時需要考慮使用場景,把自己當成用戶,看看產(chǎn)品在真實的使用場景下能否跑通。所以,產(chǎn)品驗收有時不僅會涉及到bug修改,有時可能需要進行需求調(diào)整。
二、產(chǎn)品驗收怎么做
驗收前期準備
驗收前期準備包括:
- 需求清單:需求清單一般在產(chǎn)品文檔中都有寫,如果沒有,可以對照原型自己列一個。
- 產(chǎn)品原型:產(chǎn)品清單往往不夠詳細,具體的功能可以對照原型進行驗收。
- 測試用例:如果有測試用例,那就最棒棒噠,如果沒有的話,可以自己列一個。
注意,如果不是自己的需求,首先需要把需求搞懂再進行驗收。如果對需求一知半解,驗收時往往不能發(fā)現(xiàn)問題,或者本來不是問題自己卻當成了問題。
在進行產(chǎn)品驗收之前或者產(chǎn)品驗收的同時,可以找設計同學進行UI驗收,檢查最終的產(chǎn)品與設計圖是否相符合。
驗收環(huán)境
產(chǎn)品驗收和測試一樣,是需要分階段做的,一般測試和驗收需要在以下幾個環(huán)境中進行:
- 測試環(huán)境:開發(fā)完成后會提測到測試環(huán)境,測試環(huán)境中的數(shù)據(jù)都是可以隨意瞎編的,在測試同學測得差不多的時候,產(chǎn)品經(jīng)理就可以介入驗收了。測得差不多的標準就是:所剩的bug優(yōu)先級不高,對產(chǎn)品功能沒有大的影響。有時可能因為信息不對稱,產(chǎn)品經(jīng)理會在發(fā)布到預發(fā)布時再進行驗收,但是在預發(fā)布發(fā)現(xiàn)需要需求修改或者發(fā)現(xiàn)比較嚴重的問題時再讓開發(fā)修改就會比較緊張。所以及時關注測試報告和JIRA,及時跟進測試進度是非常必要的。
- 預發(fā)布環(huán)境(預上線環(huán)境):測試環(huán)境發(fā)現(xiàn)沒問題了,就會發(fā)布到預發(fā)布環(huán)境,預發(fā)布環(huán)境的數(shù)據(jù)跟線上環(huán)境相同,所以在驗收的時候要注意按照規(guī)范進行測試驗收,不要把數(shù)據(jù)庫搞得亂七八糟。有些問題在測試環(huán)境中發(fā)現(xiàn)不了,在預發(fā)布環(huán)境進行驗收和回歸是很有必要的,驗收完成,沒有問題,就可以申請上線了。
- 生產(chǎn)環(huán)境(線上環(huán)境):產(chǎn)品上線后需要進行最后一輪驗收,如果發(fā)到線上發(fā)現(xiàn)比較嚴重的問題就需要回滾或者hotfix,可憐,摸頭,祝好。
驗收的過程
需要我們對照我們準備的材料,對每一個功能進行使用。不斷點擊,不斷和系統(tǒng)交互,至少要對照需求清單、原型和測試用例過個兩遍,千萬不能憑記憶,即使自己設計的也可能有細節(jié)會漏掉;
如果有些功能沒有辦法測試或者不懂怎么測試,比如埋點或者需要調(diào)用接口的功能,可以搬著小凳子去測試同學那里看他們測試,了解測試結果,如果有什么情況他們沒有考慮到,需要隨時指出來并進行確認。
三、需要注意的點
UI驗收
適配問題:對app進行驗收時,需要多找?guī)讉€手機看看,檢查每一個頁面的適配問題。對網(wǎng)頁進行驗收時,由于開發(fā)、測試、設計一般都用大屏,需要在小屏幕筆記本上看一下是否存在適配問題,窗口拉大縮小看看UI是否存在問題。
功能驗收
異常情況:雖然測試會測,但是我們驗收時也需要注意異常情況,比如網(wǎng)絡異常、輸入異常等。
真實場景:驗收把自己想象成小白用戶,在真實場景下整個流程是否能跑通。最懂需求的我們可能覺得設計得很合理,但是小白用戶可能并不知道如何使用,這時需要考慮增加使用幫助或使用引導。也可以找?guī)讉€沒有接觸過該產(chǎn)品的同事用一下,看看有什么問題。
另外,我們可以把自己驗收時經(jīng)常遇到的問題匯總起來,建立自己的驗收checklist,比如我的checklist中記錄有:
- 有列表的時候就需要排序,排序規(guī)則;
- 文本框考慮空格;
- 選擇:全選、全不選、單選、多選;
- 當有跨頁選擇或顯示時需要考慮跨頁;
- 數(shù)據(jù)異常:數(shù)據(jù)過長,數(shù)據(jù)為空時的展示;
…….
balabala巴啦啦小魔仙咒語一呼喊就開展正義的一戰(zhàn)~
…….
四、產(chǎn)品驗收報告怎么寫
每輪產(chǎn)品驗收完成后需要寫一個驗收報告同步給測試和研發(fā),驗收報告中需要注明:
- 基本信息:項目名稱、版本號、驗收人員、驗收時間、設備、系統(tǒng)版本……
- 優(yōu)先級:不管是ABCD還是高中低,優(yōu)先級都是必須要注明的,重要緊急的問題本期必須修改,而問題不太重要時間又比較緊張可以放在后續(xù)的迭代中修改;
- 功能所屬部分:是服務端還是客戶端;
- 功能所屬模塊:比較大的模塊,方便定位,比如是首頁還是個人中心;
- 功能名稱:具體是哪個功能,功能名稱是什么;
- 問題描述:具體描述問題是什么,可以附上截圖;
- 時間:發(fā)現(xiàn)問題的時間需要注明;
- 處理情況:回歸的時候可以標記一下處理情況。
本文由 @Alex是誰 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash ,基于 CC0 協(xié)議
贊
能寫出這樣的文章,怎么能說是小白,至少是個大白
不錯,反映了當前社會問題,值得引人關注
注意,如果不是自己的需求,首先需要把需求搞懂再進行驗收。如果對需求一知半解,驗收時往往不能發(fā)現(xiàn)問題,或者本來不是問題自己卻當成了問題。
為啥自己的產(chǎn)品文檔里會出現(xiàn)不適自己的需求、沒有搞懂的需求?
在敏捷開發(fā)里面有可能存在需要驗收別人prd的情況。
這么說吧,例如淘寶APP,肯定不止一個產(chǎn)品經(jīng)理,但是在一個開發(fā)版本中,肯定含有不同產(chǎn)品經(jīng)理負責的需求內(nèi)容。所以就會存在不是自己經(jīng)手的需求。最常見的就是移動端是一個產(chǎn)品經(jīng)理,管理后臺是一個產(chǎn)品經(jīng)理