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，從入門到放棄》
文章列表
留言列表
