起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從測試人員的角度看敏捷中的障礙
Scrum是一種迭代式與增量式的框架，它體現了軟件開發的一種敏捷式的途徑。在軟件組織中，使用Scrum進行軟件應用開發與測試正在變得越來越流行。
在Scrum團隊中，測試與開發同樣重要。在每個Sprint中，測試人員需要在特定的、極短的時間內對特性進行測試，以幫助團隊盡早地消除bug。
雖然敏捷測試比起傳統的測試方法存在著許多優勢，但它也有不足之處，其中之一就是有時它會在每個Sprint臨結束時對質量保證（QA）團隊產生了過多的壓力，最終可能會導致Sprint的溢出。
測試人員所面對的另一個問題是缺乏全面的文檔。在敏捷項目中有一個嚴重的陷阱，就是缺乏對設計與文檔的強調，因此造成了許多需求的模糊不清。雖然人們說過多的細節文檔會妨礙重要的工作，但我認為可以在某個敏捷項目管理工具中維護每個用戶故事的適當細節、文檔以及每種可能的場景，以此解決這一問題。
QA團隊無法對幾周之后的工作內容進行規劃，在敏捷項目中，測試人員必須在代碼開發的同一個迭代內進行代碼的測試，并且要求他們為代碼及整個應用提供快速的反饋。不過，在大多數情況下，可運行的代碼只在一個Sprint臨近結尾時才能夠提交，此時由于demo或演示的需要，代碼往往要處于凍結狀態。其結果就是測試團隊往往缺乏足夠的時間進行驗證，因此往往對某個特定Sprint的測試會推遲到下一個迭代中，此時才會將這些工作丟給測試團隊。
在Scrum，測試人員的工作不僅僅是進行測試，并在缺陷跟蹤工具中記錄bug，而是包含了多種不同的任務，例如測試管理和分析以及測試執行的職責。除此之外的職責還包括客戶處理，以及bug的跟蹤，還有將客戶不斷建議的頻繁變更進行集成。
真正的敏捷QA往往還要負責非單元測試工具、測試環境搭建以及測試數據的準備。處于這一角色上的人會發現他們需要在互相沖突的選擇中進行權衡。這些選擇與非敏捷項目中的選擇相類似，但由于敏捷項目的時間短暫，使這些問題顯得更為突出。對于測試進行管理的職責往往分派給某個敏捷團隊中的一個或兩個成員，而不是由整個團隊承擔起這一任務。
雖然在敏捷項目中進行工作會讓你始終保持警覺，但分散的職責以及更好的時間管理能夠讓你的工作更簡單，同時也更高效。
時間估算是敏捷測試人員的一大挑戰，要進行準確的測試估算，需要考慮到多個重要的因素，例如項目的范圍、所需的測試類型、測試任務以及以往的經驗。但有時即使是最精確的估算方式也會最終顯得時間不足，這是因為每個Sprint結束前的測試時間過于短暫，因此QA無法進行足夠的端到端測試。如果在先前的開發過程出現了任何延遲，都有可能影響QA的時間安排，有時QA無法在整個迭代中完成某個測試用例的執行，因此他只能選擇快速的完成。在估算過程中，QA有責任提醒整個團隊必須執行的測試任務，因此讓團隊成員不會對任務過分承諾。這里的估算應當包括手工任務和自動化任務，團隊或許需要對某個用戶故事編寫或改寫自動化測試。
在敏捷測試中的另一個障礙是在測試過程中缺乏客戶的參與，客戶或許會認為他們只需要在產品完全結束之后再參與就足夠了。這會導致驗收測試和驗收標準方面的問題。我們在演示過程中很少會收到下一步應該做些什么的反饋。建立一種信任關系有助于緩解這一風險。
在我之前的一個項目中，我曾看到客戶建議對應用程序的核心功能進行巨大的改動。這種改動會影響應用程序中的其它特性，并且導致代碼的改動，并且使測試工作量倍增。從客戶那里得到的反饋時間太晚，會推遲產品上線的時間。讓業務人員專門負責與客戶進行每日溝通，能夠填補在客戶響應時間上的鴻溝。
敏捷的一個主要優勢是能夠盡早地開始測試。隨著項目逐漸成熟，敏捷測試也變得越來越重要。每個特性在開發完成之后就應當進行完整的測試，而不是在整個開發結束后再開始測試。
在項目的早期完成了幾個成功的迭代之后，用戶故事與工作量會開始增長，而項目也需要加入更多的團隊成員。隨著開發人員數量的增長，測試人員的數量也應當隨之增長，以維持一個恒定的測試人員/開發人員的比例（通常是一個測試對應兩個開發人員）。
現在，讓我們假設以上情形在每個Sprint（大約兩周到四周）中都會重復出現。從客戶的角度來看，在每個循環中，敏捷測試都需要對一個或多個新的軟件模塊進行驗證。還需要考慮在最終發布之前如何、以及何時處理回歸測試的問題。測試不再是軟件開發的一個階段，而是與開發混合在一起，持續的測試是確保持續前進以及最終成功的咒語，也是唯一的方法。
在每個Sprint的過程中，敏捷測試將對每個新的功能進行檢驗。通常來說，在每個Sprint的結束之前，需要保留一小段時間以進行回歸測試，然后才能進入下一個Sprint。敏捷團隊常常會實現一種構建驗證測試（BVT）程序，團隊通過它實施一個標準的驗證步驟集，它將橫跨整個應用程序，以確保應用程序的穩定性與功能性。如果可能的話，應當將這種程序進行自動化，并集成為持續集成服務器的一部分，這將使發布過程更加嚴格。
對于跨多個Sprint的項目來說，一種標準的實踐是在其中設置一個代碼強化Sprint，或發布Sprint，從整合的觀點來看，能夠確保應用程序的整體功能。良好的情況下，假設在每個Sprint中都小心翼翼地處理了缺陷的問題，那么這個過程不應該超過30天或45天。可以通過為每個用戶故事和bug設定手動與自動化測試的目標以實現這一點。QA有責任將任何尚未實現自動化的用戶故事和bug標注為手動。這樣，在新的構建部署之前，我們就能夠獲得一個可以手動執行的回歸測試的集合。對于自動化來說，我們應該維護一個良好的自動化測試套件，在開發者每次提交代碼時作為一個持續集成任務自動運行。
每個Sprint中，我們都在添加新的特性，或是發動現有的特性。我們也需要確保之前所創建的功能還在繼續正常運行。一個自動化測試框架能夠幫助團隊快速地進行測試并找到bug。這不僅是對于新的開發任務所產生的回歸缺陷的一種安全保障，同時也節省了開發者與測試人員的寶貴時間，讓他們專注于自己最擅長的工作上。
但是，由于每個Scrum Sprint的時間限制，同時編寫自動化測試用例以及進行手動測試就成為一個很大的挑戰。為了克服這一挑戰，我們團隊對于每個用戶故事完成的定義加入了一個規定：如果某個用戶故事的適當路徑（happy path）還沒有完成自動化，那么就不能夠開始進行測試。通常來說，讓一個開發者與一個QA測試人員共同合作編寫適當路徑是一種優秀的實踐。
有些情況下，在一個Sprint中對非功能性方面進行測試是不可能的，例如系統的性能。對于每個非功能性方面的測試都應當創建新的用戶故事，并獨立估算時間。此外，這些測試也應當實現自動化，并加入到回歸測試套件中，以確保缺陷修復后的系統還能夠繼續正常運行。如果整個系統是持續集成的，并且使用了自動化測試，那么也許就不必對其進行嚴格的集成測試了。
雖然在瀑布式、迭代式與敏捷實踐中測試的任務從原則上來說沒有什么區別，但敏捷的心態與它的測試實踐為實現理想的結果提供了新的有效方法。敏捷性體現在敏捷實踐當中，而不是體現在支配性的流程中本身。
簡而言之，一個優秀的敏捷測試人員應當具備處理多任務的能力，并且能夠跟上開發與發布的節奏。對于測試人員來說，創新性比挑剔來得更為重要。一個測試專家應當努力進行學習與創新，并且對于客戶的期望必須具備全面的理解。最后，一個敏捷測試人員必須具備多種技術，例如手動測試、功能性測試和性能測試，并且需要具備領導能力和溝通能力這樣的軟技巧。
本文轉載自：InfoQ中文站
作者：Priyanka Hasija，是一位來自于Thoughtworks的QA咨詢師，她在IT行業有5年的從業經驗。在這段時間時，她對于敏捷的原則已經建立了一個堅實的認識，并且在多個敏捷項目中成功地實踐了這些原則。Priyanka在手動測試方面獲得了豐富的經驗，并且在使用自動化測試工具方面也經驗頗豐，這些工具包括Cucumber、Web-driver和JMeter等等。她也在內部與外部的多個會議上進行了演講。
測試用例