敏捷軟件測試常見的七個誤區(2)

　　至于關于自動化測試維護成本的顧慮，敏捷項目也確實存在變化比較多的特點，但通常變的都是比較接近用戶的部分，所以應該盡量減少用戶級別的依賴界面的自動化測試，而多增加一些不容易變化的底層的單元測試接口測試等。

　　推薦敏捷測試以自動化測試為主，手動測試為輔。

　　敏捷QA = 敏捷Tester

　　在很多剛接觸敏捷實踐的團隊中，大家對敏捷QA的認識還停留在Tester的階段，認為只要用戶故事開發完成之后，QA去專職地做測試，發現缺陷就夠了。

　　這是一個很大的誤解，首先QA(Quality Assurance/Analyst)，不是單純意義的測試人員，通過這個角色的名稱我們可以看的出來敏捷QA強調的是質量保障和分析，而不單純是測試產品。

　　在實際的項目中，敏捷QA通常會從需求分析階段就開始參與整個軟件開發過程，通過在不同階段和團隊中的不同角色合作，幫助整個團隊對質量達成共識，并通過在不同階段的確認和驗證做到缺陷預防，而不是等到軟件開發完成后再去發現缺陷，所以對于敏捷QA來說，其目標是軟件開發完成后能夠發現的缺陷越少越好，而對于Tester來說，發現越多的缺陷證明工作做得越優秀。

　　非功能性測試不重要

　　非功能性測試指的是針對非功能性需求(軟件本身滿足用戶需求所必需的功能性需求以外的一些特性，比如安全，性能，可用性，兼容性等)的測試，通常包括安全測試，性能測試，可用性測試，兼容性測試等。

　　在敏捷軟件項目中，需求被切割成了很小的單元，在切割的過程中，非功能性需求是最容易被人忽略的一部分，而這導致的問題就是非功能性測試經常被團隊忽略，久而久之，就會形成這樣一個誤解，認為非功能性測試是不重要的。

　　這個觀點非常不對，首先非功能性測試的重要性并不會因為軟件開發模式的不同而有所不同，尤其安全測試和性能測試的重要性正越來越多地被重視起來，因為很多產品必須考慮到用戶敏感信息的安全以及性能導致的用戶滿意度，在敏捷項目中由于軟件會盡早發布，如果這些非功能性需求出現問題，就會更早地造成影響，很可能在軟件剛步入市場就損失掉大多數的用戶。

　　所以非功能性的測試和功能性測試同等重要，在實際的項目中，比較好的做法是將這些非功能性需求也加入到用戶故事的驗收條件中，在整個敏捷開發流程中對這些非功能性需求進行驗證。

　　質量是QA的事兒

　　受傳統觀念的影響，很多人還是會認為質量是QA的事兒，如果產品發布后質量不好是QA的問題，其他角色和質量沒有太大的關系。

　　首先這種認識太高估了QA對質量的作用，軟件的質量是在軟件開發過程中逐步形成的， 從需求分析階段是否真正的了解到了客戶想要的功能，到開發階段是否增加了足夠多的自動化測試保障，是否寫了足夠健壯的產品代碼，到最后測試階段是否測試了功能引入后整個系統的可用性，不同用戶路徑是否能正常工作等等，這些都是軟件質量的組成部分。

　　可以看得出來，在整個過程中，軟件的質量離不開敏捷團隊各種角色的付出，其中有業務分析人員對需求的準確把握，有開發人員對產品代碼的高標準實現，對自動化測試覆蓋率的保障，還有QA在整個過程中對質量相關活動的實施和保障，包括需求分析階段從QA的視角對業務的補充，開發階段對自動化測試的審查，以及探索性測試可用性測試等對產品質量的進一步保障。

　　所以在敏捷測試中更多時候我們會淡化角色的概念，強調團隊人人都為質量負責，這樣更有助于團隊的每一位成員都把質量作為非常重要的一部分，而不是依賴于某個人或者某個角色。

　　開發可以寫測試，不再需要QA了

　　因為敏捷團隊強調人人都為質量負責，開發人員會采用TDD等方式寫大量的自動化測試，那么是不是就不需要QA了?

原文轉自：http://insights.thoughtworkers.org/agile-testing-misunderstanding/?utm_source=tuicool&utm_medium=referral