測試自動化后，我們還需要QA嗎？

　　QA的職責

　　我們先討論一下傳統的瀑布模型下QA是如何工作的，其中最主要的問題是什么;然后作為對比，我們來看看在敏捷團隊里QA又是如何工作的，工作重點又是什么;最后，我們詳細看一看在新的職責下，QA應該如何做。

　　瀑布開發模型

　　即使在今天，在很多企業中，瀑布模型仍然是主流。每一個需求都需要經過分析，設計，開發，測試，上線部署，運維等階段。雖然一些企業已經在實施敏捷開發，比如項目/產品以迭代的方式運作，也有諸如每日站會，代碼檢視等敏捷實踐，但是如果仔細審視，你會發現其實開發模式骨子里還是瀑布：按照軟件組件劃分的部門結構(詳見康威定律)，按照職能劃分的團隊(開發和測試分屬不同部門)，過長的反饋周期，永遠無法擺脫的集成難題等等。

　　隨著軟件變得越來越復雜，團隊里沒有任何一個人可以說出系統是如何運作的，也不知道最終用戶是誰，以及最終用戶會以何種方式來使用最終的軟件。

　　更糟糕的是，按照職能劃分的團隊在物理上都是隔離的，比如獨立的測試部門，獨立的運維部門，整日忙碌而難以預約到檔期的業務人員，當然還有經常疲于交付，無處吐槽的苦逼開發。由于這些隔離，信息的反饋周期會非常長，一個本來很容易修復的缺陷可能在4周之后才可能被另一個部門的測試發現，然后通過復雜的工作流(比如某種形式的缺陷追蹤系統)流到開發那里，而開發可能還在拼命的完成早就應該交付的功能，從而形成惡性循環。

　　瀑布模式中的QA

　　在這樣的環境中，QA們能做的事情非常有限。在需求開始時會他們參加需求澄清的會議，制定一些測試計劃，然后進行測試用例的設計。有的企業會用諸如Excel之類的工具來記錄這些用例。這些寫在Excel里的，死的用例用處非常有限。而最大的問題在于：它們無法自動化執行。另外，在實際軟件開發中，需求總是會經常發生變化，需求的優先級也會有調整，然后這些記錄在Excel中的死的用例會很快過期，變得無人問津。

　　除此之外，QA中的有些成員會使用工具來錄制一些UI測試的場景，然后在每個新版本出來之后進行回放即可。然而，當UI發生一點變化之后，這些自動化的用例就會失效：比如HTML片段中元素位置的調整，JavaScript的異步調用超時等等。

　　顯然，這種單純以黑盒的形式來檢查功能點的測試方式是不工作的，要真正有效的提升軟件質量，僅僅通過事后檢查是遠遠不夠的，軟件的質量也應該內建于軟件之中。QA的工作也應該是一個貫穿軟件生命周期的活動，從商業想法，到真實上線，這其中的所有環節，都應該有QA的參與。

　　系統思考

　　如果不從一個系統的角度來思考軟件質量，就無法真正構建出健壯的、讓業務和團隊都有信心的軟件系統。質量從來都不只是QA的職責，而是整個團隊的職責。

　　關于軟件質量，一個根深蒂固的誤解是：缺陷在開發過程中被引入，然后在測試階段被發現，最后在QA和開發的來來回回的撕扯中被解決(或者數量被大規模降低)，最后在生產環境中，就只會有很少的，優先級很低的缺陷。

　　然而事實上，很多需求就沒有仔細分析，業務價值不很確定，驗收條件模糊，流入開發后又會引入一些代碼級別的錯誤，以及業務規則上的缺陷，測試階段會漏掉一些功能點，上線之后更是問題百出(網絡故障，緩存失效，黑客攻擊，操作系統補丁，甚至內存溢出，log文件將磁盤寫滿等等)。

　　在一個敏捷團隊中，每個個人都應該對質量負責，而QA則以自己的豐富經驗和獨特視角來發掘系統中可能的質量隱患，并幫助團隊將這些隱患消除。

　　我在ThoughtWorks的同事Anand Bagmar在他的演講What is Agile testing- How does automation help?中詳細討論過這部分內容。

　　QA到底應該干什么?

　　本質上來說，任何軟件項目的目標都應該是：更快地將高質量的軟件從想法變成產品。

　　將這個大目標細分一下，會得到這樣幾個子項，即企業需要：

　　更多的商業回報(發掘業務價值)

　　更快的上線時間(做最簡單，直接的版本)

　　更好的軟件質量(質量內嵌)

　　更少的資源投入(減少浪費)

　　其實就是傳說中的多、快、好、省。如果說這是每一個軟件項目的目標的話，那么團隊里的每一個個人都應該向著這個目標而努力，任何其他形式的工作都可以歸類為浪費。用Excel記錄那些經常會失效，而且無法自動執行的測試用例是浪費，會因為頁面布局變化而大面積失效的UI測試也是浪費，一個容易修復的缺陷要等到數周之后才被發現也是浪費。

原文轉自：http://icodeit.org/2016/09/what-should-qa-do-in-a-agile-team/