測試-專案流程
認知
剛到公司的時候，看著專案流程，感覺為啥要這麼麻煩。專案流程中要關注的點太多了，能記下這麼多環節就已經不錯了，還要按照這個流程執行，著實有些困難。
但是當你工作一段時間後，你就會發現專案流程的重要性，因為專案流程就是你的套路，沒有套路是工作中很可怕的一件事情；有了套路你可以避免很多共性的錯誤。套路即是你工作經驗的總結。
在你缺少經驗的時候專案流程可以使你避免犯錯，在你經驗豐富的時候還要通過你的經驗去完善你的專案流程，更多地去避免犯錯。專案流程不是一成不變的，是根據工作情況逐漸完善的。
以上說的總結兩點，一是專案流程的意義，二是專案流程是需要不斷完善的。
幾個階段
流程中到底要分幾個階段，這個不是我們靠腦子憑空想的，回到第一節講的，是我們工作中根據實際情況逐漸完善的。那麼我們就要想一下，我們在工作中都有哪些階段。
首先我們要有一個需求，有了需求我們就要把它變成程式，並且驗證它是我們想要的，最後給使用者去使用，釋出後我們還要一個反饋。這就是一個完整的需求上線流程。我們將上面的流程抽象為幾個大的流程。
- 需求階段
- 設計開發
- 測試
- 釋出
- 釋出後
需求階段
一個需求也有它自己的生命週期，從產生到決定開發，這個階段就是我們在需求階段所要關注的東西。除此之外我們需要圍繞需求做一些輔助效率的事情，例如講一個群溝通，確認一下上下游業務，確認一下系統結構
需求階段主要有以下幾個關注點
- 需求評審
- 業務確認
- 溝通群
- 系統結構確認
- 許可權確認
需求產生的幾個途徑
首先一個需求又會由哪些方式產生呢？對於我所在的機票行業來說，主要有航司的規定、運營流程的改進、運營資料的支撐和由bug帶來的業務認知。對於其他行業來說，更多的是產品們的頭腦風暴產生的。
- 航司的規定：這個是行業的標準。
- 運營流程的改進：根據現有流程分析，提高效率的需求。
- 運營資料的支撐：根據自己的推測，上線部分功能，產品逐步迭代。
- 由bug帶來的業務認知：因為許多行業標準我們不瞭解，bad case就是我們最好的老師。
需求review與finally review
當一個需求由產品提出，我們就要對這個需求進行評估，評估它的價值。沒有價值的需求我們沒有必要去做它。由於Qunar給了每個人許多權力，需求是否通過是參與需求評審三方（PM、DEV、QA，主要是各組的負責人）共同決定的，任何一方提出異議，需求都不會通過。當我們需求評審通過後，老大們會進行一個最終評審，決定是否去做這個需求。在需求階段就要有需求review和需求finally review。
業務確認
在做一個需求的同時我們要考慮的不僅僅要關注當前需求，在整個業務線，你的需求處於哪個環節？是否與現有業務具有衝突？你評審需求的根據也是從已有業務觸發。所有你要兩部分，即當前需求和上下游業務。
當前需求你要關注：業務是什麼？要解決什麼問題？
上下游業務你要關注：整體業務是什麼？你的業務處於哪一環節？
系統結構確認
對於Qunar的QA來說，我們在測試中要關注程式碼，進行code diff，在確認業務之後，我們要了解相關的系統結構，與業務結合起來，瞭解功能與程式碼的對應關係，測試中可以方便查詢關鍵日誌、快速定位問題。
溝通群
當我們計劃開始做這個需求了，我們要開始召集人馬了，就要使用溝通工具，去幫助我們溝通，Qunar內部使用的是qtalk，也可以用QQ、微信等。這個階段我們就要拉個群，三方及其TL，還有各位大佬們。出現問題，儘量在群裡溝通，讓關注此專案的人都可以第一時間瞭解專案的進度。
許可權確認
開發的程式碼、測試環境、是否有釋出許可權（Qunar是QA釋出，需要申請每個工程的許可權），這些許可權最好提前確認好，避免在用的時候，才發現沒有許可權，這樣會浪費許多時間。
設計開發
為什麼這個階段叫設計開發，不是單純的開發階段？
因為這個階段除了我們的DEV在瘋狂的編碼中，QA也在發揮自己的價值，提供一些測試點，PM也沒有閒著，在Qunar case是由產品寫的，這一點是網際網路公司中獨一無二的。
那麼這個階段，我們的流程就要分開去說明，按照每個職責劃分。
QA
瞭解設計
QA需要提前瞭解開發是如何設計的，因為不同的技術方案對我們的測試影響很大，不同的技術方案可能會有不同的測試方案。
checklist
checklist作為評估需求測試點的工具，是評判一個QA水平最基本的技能，QA需要將需求的所有測試點都列出來，作為本次測試工作的指導依據。在這個階段QA需要提供本次需求的checklist，並且儘量要早地提供出來。
進度把控
QA是對質量負責，專案是否能如期上線，也是QA的主要職責，在這裡我們需要每天關注需求的進度，是否有提測delay風險。一般以早晨站會的形式，關注所有對應開發組的專案進度。
DEV
code
編碼是開發的主要職責，在開始前，需要與需求review的同學或者Tl進行技術方案的確認，這個一定要做，不要到了code review階段才發現與最初的設想不同，可能導致需求delay。
code review
為了在開發階段就發現設計的問題，避免到了測試階段才發現，所有code review要儘早，並且更多地指出設計模式等問題。
提交測試申請
開發在code及code review後就會移交給QA，進入到測試階段。這個階段我們還要做一些事情，那就是要滿足我們的提測標準，這個標準對需求質量控制的重要手段。
PM
case
即測試用例，Qunar的產品要根據checklist寫case，case會作為我們提測驗收的標準。
專案進度郵件
專案從開始到結束，產品都應該每天傳送專案進度郵件，講進度及時周知出來。
三方共同
checklist review
checklist需要進行三方review，檢驗我們的checklist是否有遺漏。這裡一定要三方進行，避免資訊不對等。
case review
case同樣需要進行三方review，並且case在review後作為我們的要收標準，在提測質量保證中起到重要作用。一旦case被開發執行且通過，在測試階段出現過多，可以根據標準進行質量通報。
checklist&case在review中經常因為時間等原因，合併為一次進行，對於小的專案來說，這是可以的，但是對於比較的專案，還是建議分開進行。
checklist&case在review後我們還要根據review的結果修改或者補充。
需求變更
在開發中發現需求本身存在缺陷，三方均可提出，並且評估風險，是否需要進行需求變更，DEV和QA需要給出需求變更所帶來的工時變化，由產品同學以郵件的形式周知出來。