更好的敏捷測試之路

Capgemini 創建的年度世界質量報告顯示，42% 的受訪者將“缺乏專業測試專業知識”列為將測試應用於敏捷開發的挑戰。 雖然敏捷的出現為軟件開髮帶來了迭代速度的提高，但在某些情況下，這是以質量為代價的。

激烈的競爭迫使團隊不斷提供新產品更新，但這有時會帶來自身的成本，包括對測試的關注減少。 有些人，比如 Rob Mason，走得更遠，認為敏捷正在扼殺軟件測試。 最近，Facebook 將其座右銘從“快速行動，打破常規”改為“快速行動，穩定的基礎設施”，試圖化解犧牲質量的誘惑。

那麼，測試如何才能更好地融入敏捷軟件開發的新世界呢？ 敏捷測試。

傳統的測試非常繁瑣，並且依賴於大量的文檔。 敏捷測試是一種模擬敏捷軟件開發原則的測試過程方法，其中：

• 測試進行得更頻繁，
• 測試更少地依賴文檔，更多地依賴團隊成員的協作，並且
• 一些測試活動不僅由測試人員進行，也由開發人員進行。

在過去的七年裡，我已經將許多團隊轉變為敏捷測試，並與測試人員並肩工作，以幫助他們的流程適應新的方法。 在本文中，我將分享一些我在實現更好的敏捷測試的過程中學到的最有影響力的技巧。 雖然敏捷實踐中速度和質量之間存在摩擦是很自然的，但本文將介紹一些可用於在不影響敏捷性的情況下提高測試質量的技術。 此處列出的大多數建議都需要團隊的參與，因此讓開發人員和測試人員都參與規劃將是有益的。

正式發布測試週期過程

測試的一個問題是缺少發布測試週期、沒有發佈時間表或不定期的測試請求。 按需測試請求使 QA 過程變得困難，尤其是在測試人員處理多個項目時。

許多團隊在每個 sprint 之後只進行一次構建，這對於敏捷項目來說並不理想。 轉向每週一次的發布可能是有益的，逐漸過渡到每週多次構建。 理想情況下，開發構建和測試應該每天進行，這意味著開發人員每天將代碼推送到存儲庫，並且構建計劃在特定時間運行。 為了更進一步，開發人員將能夠按需部署新代碼。 為了實現這一點，團隊可以採用持續集成和持續部署 (CI/CD) 流程。 CI/CD 限制了在主要版本發布當天構建失敗的可能性。

當 CI/CD 和測試自動化相結合時，早期發現關鍵錯誤是可能的，使開發人員有足夠的時間在計劃的客戶端發布之前修復關鍵錯誤。 敏捷的一項原則指出，工作軟件是衡量進度的主要標準。 在這種情況下，正式的發布週期使測試過程更加敏捷。

使用部署工具授權測試人員

測試的常見摩擦點之一是將代碼部署到暫存環境。 此過程取決於您的團隊可能無法影響的技術基礎設施。 但是，如果有一定的靈活性，可以為測試人員或項目經理等非技術人員創建工具，允許他們部署更新的代碼庫以進行自己的測試。

例如，在我的一個團隊中，我們使用 Git 進行版本控制，使用 Slack 進行通信。 開發人員創建了一個可以訪問 Git、部署腳本和一個虛擬機的 Slackbot。 測試人員能夠使用從 GitHub 或 Jira 獲取的分支名稱 ping 機器人，並將其部署在暫存環境中。

當測試人員不得不要求開發人員部署一個分支進行測試時，這種設置為開發人員騰出了大量時間，同時減少了通信浪費和持續中斷。

試驗 TDD 和 ATDD

測試驅動開發 (TDD) 是一種非常重視質量的軟件開發過程。 傳統上，開發人員編寫代碼，然後有人對其進行測試並報告是否發現了任何錯誤。 在 TDD 中，開發人員首先編寫單元測試，然後再編寫任何可以完成用戶故事的代碼。 測試最初會失敗，直到開發人員編寫了最少量的代碼來通過測試。 之後，重構代碼以滿足團隊的質量要求。

驗收測試驅動開發 (ATDD) 遵循與 TDD 類似的邏輯，但顧名思義，它側重於驗收測試。 在這種情況下，驗收測試是在開發之前與開發人員、測試人員和請求者（客戶、產品所有者、業務分析師等）合作創建的。 這些測試幫助團隊中的每個人在編寫任何代碼之前了解客戶的需求。

TDD 和 ATDD 等技術通過將測試過程移至開發生命週期的早期階段，使測試更加敏捷。 在早期編寫測試場景時，開發人員需要非常了解需求。 這最大限度地減少了不必要的代碼創建，並解決了開發週期開始時的任何產品不確定性。 當產品問題或衝突僅在後期出現時，開發時間和成本就會增加。

通過跟踪任務卡移動發現效率低下

在我的一個團隊中，我們有一位開發人員非常快，尤其是在小功能方面。 他會在代碼審查期間收到很多評論，但我們的 Scrum master 和我因為缺乏經驗而把它寫下來。 然而，隨著他開始編寫更複雜的功能，問題變得更加明顯。 他開發了一種在完全準備好之前將代碼傳遞給測試的模式。 這種模式通常在開發過程缺乏透明度時形成——例如，不清楚不同的人在給定任務上花費了多少時間。

有時，開發人員匆忙工作，試圖盡快推出功能並將質量“外包”給測試人員。 這樣的設置只會將瓶頸移到 sprint 的下方。 質量保證 (QA) 是團隊擁有的最重要的安全網，但這可能意味著 QA 的存在使開發人員能夠放棄質量考慮。

許多現代項目管理工具能夠跟踪 Scrum 或看板上的任務卡的移動。 在我們的案例中，我們使用 Jira 分析了相關開發人員的任務發生了什麼，並與團隊中的其他開發人員進行了比較。 我們發現：

• 他的任務在我們板子的測試欄中花費了幾乎兩倍的時間；
• 他的任務通常會從 QA 中返回，以進行第二輪或第三輪修復。

因此，除了測試人員必須在他的任務上花費更多時間外，他們還必須多次執行。 我們不透明的過程使開發人員看起來非常快； 然而，當我們考慮到測試時間時，這被證明是錯誤的。 來回移動用戶故事顯然不是一種精益方法。

為了解決這個問題，我們首先與這位開發人員進行了坦誠的討論。 在我們的案例中，他根本沒有意識到他的工作模式是多麼有害。 這只是他習慣了在他以前的公司工作的方式，這家公司對質量的要求較低，測試人員的數量較多。 經過我們的交談，並在與我們的 Scrum master 進行了幾次結對編程課程的幫助下，他逐漸轉向了一種更高質量的開發方法。 由於他的快速編碼能力，他仍然是一個高績效者，但消除了 QA 過程的“浪費”，使整個測試過程更加敏捷。

將測試自動化添加到 QA 團隊技能集中

非敏捷項目中的測試涉及測試分析、測試設計和測試執行等活動。 這些活動是連續的，需要大量文檔。 當一家公司過渡到敏捷時，通常情況下，過渡主要集中在開發人員身上，而不是測試人員身上。 他們停止創建大量文檔（傳統測試的支柱），但繼續執行手動測試。 但是，手動測試速度很慢，通常無法應對敏捷的快速反饋循環。

測試自動化是這個問題的流行解決方案。 自動化測試使測試新功能和小功能變得更加容易，因為測試代碼可以在後台運行，而開發人員和測試人員則專注於其他任務。 此外，由於測試是自動運行的，因此與手動測試工作相比，測試覆蓋範圍可能要大得多。

自動化測試是類似於正在測試的代碼庫的軟件代碼片段。 這意味著編寫自動化測試的人需要技術技能才能成功。 不同團隊之間實施自動化測試的方式有很多不同的變化。 有時，開發人員自己扮演測試人員的角色，並通過每個新功能增加測試代碼庫。 在其他團隊中，手動測試人員學習使用測試自動化工具或聘請經驗豐富的技術測試人員來自動化測試過程。 無論團隊採取哪種方式，自動化都會帶來更加敏捷的測試。

管理測試優先級

對於非敏捷軟件開發，測試人員通常是按項目分配的。 然而，隨著敏捷和 Scrum 的出現，相同的 QA 專業人員跨多個項目進行操作已變得很普遍。 當測試人員將一個團隊的發布測試優先於另一個團隊的 sprint 計劃會議時，這種重疊的職責可能會在計劃中產生衝突並導致測試人員錯過關鍵儀式。

測試人員有時在多個項目上工作的原因是顯而易見的——很少有穩定的測試任務流來填補全職角色。 因此，可能很難說服利益相關者將專門的測試資源分配給團隊。 但是，在不參與測試活動時，測試人員可以執行一些合理的任務來填補停機時間。

客戶支持

一種可能的設置是讓測試人員花費他們的衝刺停機時間來幫助客戶支持團隊。 通過不斷面對客戶遇到的問題，測試人員可以更好地了解用戶體驗以及如何改進它。 他們能夠在規劃會議期間為討論做出貢獻。 此外，他們在測試活動中變得更加專心，因為他們更好地熟悉了客戶如何實際使用他們的軟件。

產品管理

管理測試人員優先級的另一種技術基本上是讓他們成為執行手動測試的初級產品經理。 這也是填補測試人員下班時間的可行解決方案，因為初級產品經理花費大量時間為用戶故事創建需求，因此對大多數任務都有深入的了解。

測試自動化

正如我們之前所討論的，手動測試通常不如自動化。 在這種情況下，自動化的推動可以與讓測試人員全神貫注於團隊並利用他們的業餘時間學習使用像 Selenium 這樣的測試自動化工具一起工作。

總結：質量敏捷測試

使測試更加敏捷是許多軟件開發團隊現在面臨的必然。 然而，質量不應因採用“盡可能快地測試”的心態而受到影響。 敏捷過渡必須包括向敏捷測試的轉變，有幾種方法可以實現這一目標：

• 正式確定發布測試週期過程。
• 為測試人員提供部署工具。
• 試驗測試驅動開發和驗收測試驅動開發。
• 通過跟踪任務卡移動發現效率低下。
• 將測試自動化添加到 QA 團隊技能集中。
• 管理測試人員的優先級。

每年，軟件都在變得更好，用戶的期望也在提高。 此外，隨著客戶習慣於谷歌、蘋果和 Facebook 等頂級軟件品牌的高質量產品，這些期望也會轉移到其他軟件產品上。 因此，在未來幾年中，對質量的重視可能會更加重要。 這些測試和整體開發過程的改進可以使測試更加敏捷並確保高水平的產品質量。