身為一個專業的 QA 當然需要有自己的測試原則，這些測試原則不僅可以幫助我們提高產品質量，對外還能體現出我們的專業性，從而讓合作方後續還有意願和我們合作。
1 測試前
1.1 需求評審
必須參與，有問題隨時提出，如果涉及到相關背景資訊，讓相關同學同步一下背景資訊。
1.2 技術評審
不管能否聽懂，必須參與。
1.2.1 測試排期
在研發同學技術評審完之後，研發同學基本上可以預估自己需要多長的開發時間，所以往往技術評審會上會給出開發排期和提測時間點，這時需要我們給出我們 QA 的測試排期，下面是一個我根據經驗總結出來測試排期策略測試排期估時多長合理？：
1、以研發同學的總開發工時的一半為基調，比如如果前後端同學排期加起來 10 天，那我們的測試時間就折半，初步定在 5 ~ 6 天
2、考慮需求的複雜程度，複雜程度從兩方面體現，一是前端跟後端的改動比例，二是修改的鏈路長度，如果大部分是後端改動或者修改的鏈路較長，排期可以稍微多一兩天，反之，如果大部分是前端樣式的改動或者改動的鏈路較短，可以適當縮短排期或者維持排期不變。
3、考慮業務風險程度，對於涉及到風險程度較高的功能需求，比如涉及到賬單結算這樣的需求，可能排期會稍微多一兩天。
4、結合開發同學一貫的提測質量，如果提測質量一貫較高而且改 bug 一直都很高效，這時可以適當縮短排期或者維持排期不變，否則適當加長排期估時。
5、想想自己在測試過程中還有哪些事需要並行的做，大概會佔用多少時間，在初步確定的時間上進行調整
注意：排期不要定得太緊張，給自己留點 buffer，特別是當自己不是全人力都在當前需求測試時，更需要考慮到這方面，儘可能把排期時間加長一些。遇到特別沒把握不確定的，可以先說第一次測這塊業務或者這段時間還有xxx事在並行地做，估時先估這麼長時間，後面如果提前測完則提前上線，但也不要估時太長，這樣會讓開發和產品同學覺得你能力不行。。。
1.3 編寫checklist
1.3.1 checklist 模板
checklist 文件格式推薦使用思維導圖。比如 MindMaster 和 processon。我喜歡用這些平臺或者軟體的思維導圖大綱模式來編寫 checklist。
包含的內容：checklist 最重要的當然是測試用例，除此之外，附上相關依賴檔案和測試資料，包括：prd，技術文件，測試賬號，測試資料，測試平臺，測試環境，圖例（用紅色背景標記出 P0 的冒煙 case，藍綠色標記 checklist 評審時新增的 case ，疑問用黃色背景標註，深藍色標記checklist 評審後決定刪除的 case ）等等。checklist 編寫指南
注意：多想想需不需要驗證資料庫或者查詢日誌關鍵字來驗證鏈路節點的正確性，而不僅僅是關注黑盒入口資料和返回資料，這種是冒煙case 的測試過程，但是對於正式測試來說這不夠精細。
1.3.2 checklist 編寫時間
如果上個需求測試過程中研發同學改 bug 的時間較多導致我們需要斷斷續續地測試，那可以在閒暇時間熟悉下個需求並輸出 checklist，如果上個需求研發同學改 bug 的時間較少，對我們來說主要是連續的測試，可以在上個需求的測試過程中暫停半天或者一天，輸出 checklist，儘量在需求提測前寫好 checklist，這樣主要是為了不讓寫 checklist 的時間佔用提測之後的測試時間。
1.3.2 checklist 檔案的位置
checklist 放在統一公共資料夾下，便於後續維護管理。
1.4 checklist評審
評審之前先確認下自己是否真的準備好了怎麼確定自己的測試準備工作已經做好了？，提高評審的效率和價值。並提前在 checklist 上用紅色背景高亮標記出 P0 的冒煙 case，疑問用黃色背景標註。
評審內容：
-
與研發和產品同學核對測試用例、測試環境和測試資料等，用藍綠色標記 checklist 評審時新增的case，深藍色標記 checklist 評審後決定刪除的 case。
-
如果有疑問可以在這個會議上統一問
-
宣告需要研發同學把冒煙 case 自測通過後才能提測。否則提測打回。
評審時間：儘量在研發同學提測前評審完。不必等 checklist 完整寫完再確定評審會議的時間，因為等checklist 寫完後可能剛好這兩天研發同學和 PM 在日程上很難湊到一塊去，這就會導致評審因為沒有合適時間而延後，需要儘量避免這種情況。我們可以提前確定評審時間，比如你預估 checklist 一定可以在某個時間點完成，那麼你可以儘早拉會，先把研發和產品同學的這個時間點的日程占上，然後繼續 checklist 的編寫，這樣可以更加高效一些，最大化利用時間。
1.5 show case
show case 的意思是研發同學投屏把 P0 的 case 當場演示一遍。涉及前端改動，或者業務方較多的需求，需要讓研發同學 把主流程演示一遍，演示通過才開始測試。
2 測試中
提測前觀察流程管理平臺該需求的狀態，叮囑研發更新狀態改為「提測」，開始測試後先檢驗冒煙 case ，如果冒煙 case 未通過，直接打回提測，建議提測打回前先跟業務的測試 owner 說一下，讓他幫你評估一下是否有必要打回。
2.1 高效提問
什麼情況下發現了什麼問題，理論上應該是怎麼樣的，實際上是怎麼樣的。配圖用特殊標記和醒目的框出需要重點關注的區域，如果想更清晰一些，可以附上箭頭。特別說明：截圖截大一點，如果截個小小的區域性圖，別人很難知道你是從哪截的。
2.2 溝通過程
需求問題儘量不要私聊產品和研發同學，有問題直接在需求群裡丟擲，艾特指定的產品或者研發同學，這樣溝通效率最高，不用你反覆轉述別人的意思給其他人，且能讓其他同學明確知道目前這個需求遇到了哪些問題以及目前的一個大致測試進度。
新同學剛接手的一段時間建議每次拉需求測試群的時候都把業務的測試 owner 拉上。如果碰到無法解決的問題，可以隨時艾特或者私聊測試 owner 。
溝通時不卑不亢，千萬不要研發同學說不是問題就認為不是問題，被牽著鼻子走，要帶有質疑精神，如果你覺得不合理或者可能不符合產品預期的時候及時在群裡艾特 PM 出來確認需求。不要擔心研發同學不耐煩或者發脾氣，遇到這種情況只能說明這個同學的研發素質還有待提升，記住你幫他找出 bug，是在幫他，不是在求他。
2.2 每日進度同步
每天都需要在需求群周知測試進度，讓大家明確知道當前的測試進度和遺留的問題，儘量不要等產品或者研發同學來問進度時才說，這樣體現出我們不專業，也不利於合作。
進度同步除了告知目前測試進度和延期風險外，最好還簡單羅列一下目前遺留的問題並艾特到指定的研發同學，並周知 pm，然後附上缺陷列表連結，把整條訊息 Pin 住。
下面是一個比較好的進度模板：
2.3 注意事項
及時同步 delay 風險。任何可疑的情況都丟擲讓研發或者產品同學確認，寧可多花點時間確認，不可放過一個 bug 。
2.4 上線前回歸和線上驗收
上線後迴歸主要功能，上線後及時驗收。驗收完畢及時在流程管理平臺更新需求狀態，並在群聊中周知所有產品和開發同學。
3 測試後
更新流程管理平臺上該需求狀態為「測試完成」。如果需要填測試報告則填寫測試報告。
4 工作過程的提問
有同學可能會有這樣的想法，就是自己問問題太多會不會讓別人覺得自己能力不行，所以儘可能少提問。這裡我澄清一下：
工作中會遇到兩種問題，一種是業務問題，一種是技術問題。業務問題獨立思考的時間可以稍微短些，甚至直接請教詢問都沒關係。技術問題可以猜測和探索，獨立思考的時間允許稍微多些。
無論是技術問題還是業務問題，在知道自己無法解決後果斷詢問，不要一直卡在一個地方導致拖慢進度。獨立思考的目的一個是培養自己獨立思考和獨立解決問題的能力，另一個也是節約別人的時間。
歡迎關注公眾號 TestDevelop , 我在這裡分享各種測試開發技術知識、溝通技巧、職場感言。歡迎後續與我共同成長。
