QA,全稱為Quality Analyst，即質量分析師(有些稱為Quality Assurance,即質量保證師)。為什麼它總跟質量扯在一塊？感覺這個角色明明做的都是測試的事情，為什麼不直接叫做tester那？敏捷專案中的QA日常都做什麼事情那？可能一大推問題都會冒出來。別急，跟著我這篇文章來一步步的回答這些問題。
假設現在有一個保險公司，他想找一個軟體公司做一個線上賣保險的系統。那麼這個系統從開始到完成至少需要三個角色。
Business owner -> developer -> end user
- Business owner即保險公司的人，也是我們的需求來源，由他來提出業務需求。
- developer即軟體開發工程師，根據客戶的需求做出客戶期望的產品，最終交付給客戶。
- end user即產品的終端使用者，在本例子中即有意願在網上買保險的人。這個系統到底好不好用，他們最有發言權。（有的時候end user和business owner有可能是同一批人，比如開發的是一個內部公司使用的OA系統）。
只有這些角色能夠順利、成功的完成一個產品嗎？實際操作中肯定會遇到很多問題。這些問題會集中在兩個地方。
第一個問題出在Business owner和developer。在溝通需求的時候他們彼此會發現太費勁了。Business owner張口就來的quote、premium、policy這些名詞軟體開發工程師不懂什麼意思，因為他們沒有保險行業的背景知識，而軟體工程師喜歡說的MVC、BDD、Java之類的，Business owner也搞不懂，並且人家對這也不感興趣。那麼軟體開發工程師想，如果有人能即懂得保險行業知識，又具有IT背景，那麼分析需求肯定會順利不少。這樣的人在敏捷團隊中就叫做BA（Business Anslyst,業務分析師）。BA會理解並挖掘客戶的需求，然後將需求轉變為具體的AC(驗收條件,Acceptance critirial)，再交由開發工程師來實現。同時他也可以將業務知識最大化的傳遞給開發工程師，保證開發工程師能夠準確的理解需求（為什麼不讓Business owner直接將業務知識傳遞給開發工程師那？原因很簡單，人家可是一秒鐘幾十萬上下的主，那裡有這麼多閒工夫。）
所以系統從開始到完成變成了這個樣子。
Business owner -> BA -> developer -> end user
另一個問題就出現在了developer和end user之間。開發工程師完成的系統能夠直接拿給終端使用者用嗎？如果你說能，要麼你是對自己的產品信心十足，要麼就是盲目樂觀。我想大多數情況是後者。因為開發工程師在將業務需求轉換為編碼實現時，一方面由於理解的問題，實現或多或少可能會與需求有所偏差。另一方面由於自身思維的侷限性，會導致系統隱含了一些缺陷。假如終端使用者在使用系統時，發現線上支付有問題，或者頁面在自己所用的瀏覽器下不能正常顯示，你覺得他們還有興趣使用你的系統嗎？這就相當於把終端使用者當做系統的測試者，人家不收錢還幫助我們發現bug，那裡有這好事？系統的問題要儘可能的避免暴露給終端使用者。那麼在軟體開發工程師和終端使用者之間應該再加一個角色，就是tester。tester的主要職責就是按照AC，對系統進行功能性測試，確保功能的正確性，另一方面是針對一些非功能性測試（比如安全性測試，效能測試），保證系統的健壯性。
Business owner -> BA -> developer -> tester -> end user
做到這些的tester還不能稱之為QA，因為它的角色更像是軟體質量的看門人，最終把關者，還達不到測試分析的要求。
現在新的問題來了，到底tester什麼時候該開始對軟體的測試那？
一個極端情況是等developer把所有的功能完成以後，再交給tester來測。這樣會造成很多問題。
- 如果開發者需求理解有偏差，需要重新返工。
- 軟體中發現了bug，該功能是很久以前開發完成的，developer定位和修復要花很長時間。
- 有太多的功能需要測試，tester要花很長時間，developer又要修復發現的bug，這段時間不可預估，雖然是屬於專案上線的最後時刻，但是整個系統始終處於一個不穩定的狀態。
大家都知道在軟體工程中，需求變更發生的越晚，bug發現的越晚，會軟體開發的影響會越大。這種極端情況的做法是不可取的。
那麼應該怎麼做那？我們可以將整個系統的功能細分成很多小功能點，每一個小功能點都是獨立可測的，那麼一旦開發工程師完成此功能點，tester立馬就可以拿去測試。每一個小功能點就是敏捷中所說的使用者故事（user story）。
一個user story的典型的生命週期是這樣子的。
- backlog -> BA將剛建好的story卡放置在backlog list裡
- Analyse -> BA細化story卡，完成驗收條件等內容的編寫
- development -> 開發人員進行開發工作
- testing -> 測試人員進行測試
- UAT -> 使用者驗收測試，Business owner會對功能進行確認
- Production -> Business owner准許後，將功能釋出到生產環境
如果只是實現這樣的流程，那麼這個團隊還不算是真正的敏捷團隊，這裡的tester也不算是真正的QA。因為業務需求通過Business owner到BA再到DEV到tester，是一個衰減的過程。小時候我們玩過一個遊戲，老師讓一群人排成一排，他會給第一個人說一句悄悄話，然後讓第一個人偷偷講給第二個人，第二個人再原封不動的講給第三個人..直到最後一個人把這個悄悄話講出來和老師的原話比較，我們往往發現最後一個人的話很難和老師的原話保持一致，甚至意思會大相徑庭。那麼這就意味著tester在做測試的時候他不一定能夠真正瞭解業務的實際需求，所以在測試時難免會出現紕漏。這樣的卡最後讓business owner確認時，很難避免給business owner “驚喜”。
所以為了解決需求衰減的問題，tester要儘早的介入到的story的前期工作。在BA分析故事卡的時候，tester就可以根據卡的內容準備測試策略、測試環境，甚至準備測試資料。在開發人員領取卡的時候，tester可以從測試的角度給開發人員提供一些建議。而在開發人員開發卡的時候，tester可以和開發人員一起pair編寫自動化的測試用例。開發人員開發完畢後，tester可以在開發人員的本地環境中快速驗證其是否滿足所有驗收條件，必要的自動化測試是否已經完成等。在UAT環節，tester又可以幫助business owner進行sign off。
這個時候需求的傳遞已經不是一個簡單的鏈式的行為，測試人員作為聯結器把需求良好地串聯了起來。測試人員的職責範圍已經超出了我們通常所理解的範圍。這個時候再用tester這個稱呼已經無法涵蓋該角色的職責了。所以就有了QA（質量分析師）這一角色。可以看出在敏捷團隊中QA並不是質量的最終把關者，而是在專案開始就參與到了質量的控制當中，一直貫穿到所有環節。
如果想了解敏捷團隊中QA的具體職責，可以參見我司的同事的文章《敏捷中的QA》. 如果你想知道自己適不適合QA，請參見我司另一位同事的文章《敏捷QA，從入門到放棄》