實現ATDD的快速指南

本文為任何有興趣在他們的團隊和專案中實現ATDD的人提供了一個快速指南。它概述了遵循我介紹的敏捷方法的好處，此方法基於的是我在企業軟件開發團隊的第一手經驗。

協作是敏捷方法的核心價值觀之一。有一次，當我在做一個大型專案時，我注意到開發人員、測試人員和有業務頭腦的人之間缺乏協作;缺乏明確的需求;頻繁出現需求範圍蔓延的情況;對已完成的測試缺乏可見性;以及在專案生命週期後期才發現缺陷。對我來說最重要的是，沒有人對我們的自動化框架有任何想法，所以所有的自動化測試都是在開發了特性並準備好進行測試之後編寫的。因為這些發現，我開始研究人們是如何處理這些問題的。結果，我發現 驗收測試驅動開發(ATDD) 是用來減輕許多問題的其中一種方法。它通常與行為驅動開發(BDD)、故事測試驅動開發(SDD)和例項化需求(SBE)同義。與其他敏捷方法相比，ATDD的主要區別在於，它的重點是使開發人員、測試人員、業務人員、產品所有者和其他涉眾作為一體進行協作，並對需要實現的內容有一個清晰的理解。

根據我自己的經驗，我將分享我的想法，關於團隊如何在自己的專案中實現ATDD。

背景

我在一家有創業精神的大公司工作，所以團隊鼓勵任何創新的想法和反饋。我們很快就建立了原型，以瞭解一個想法是否會使我們的產品更好，或者有助於實現公司的總體目標。我在一個25人團隊中領導測試人員，該團隊由一個scrum master、一個技術主管和多個業務分析師、設計人員、開發人員和測試人員組成。由於創新文化的影響，團隊內部經常一片混亂，包括在功能需求上的頻繁變化，個人在筒倉環境中各自為戰，團隊士氣一直很低落。這對我來說很重要，所以我自願協助尋找這些疼痛點的解決方案，於是我找到了ATDD。

我所有和ATDD的相關總結經驗可以分為以下3個步驟。

ATDD實施週期

 

由Raj Subramanian繪製

步驟1 -訓練和實驗。

處理任務的方法有很多，特別是考慮一下，每個人可能來自於當前組織內外的不同敏捷團隊，具有截然不同的個人工作經驗。爲了能夠對團隊和組織的目標有一個共享的、共同的理解，提供適當的培訓就很重要了。關於ATDD的具體問題，它應該包括目標、目的、期望以及使用這種方法所產生的結果資訊。在培訓之後，要先開始一個小規模的實現，嘗試不同的事情並接收迭代反饋，這很重要。

例如，在研究了ATDD之後，我向不同的涉眾解釋了為什麼我們需要探索這種方法，以及會從中得到什麼好處。我強調了幾個可能的優點,如增加團隊協作、更好的澄清需求、在軟件開發生命週期(SDLC)中儘早發現缺陷,增加可見性和在SDLC早期就使用自動化，以及整個團隊參與提出明確的驗收標準。

在與利益相關者的討論中，我強調這需要一些實驗，而如果不嘗試，我們永遠無法知道它的好處。經過長時間的討論，我們決定將原來的25人分成2個小組：團隊A由12人組成，它將實現ATDD。團隊B是剩下的13人，他們將繼續保持現在的做法。

我為團隊A計劃了一個為期2天的培訓研討會，通過了解ATDD，確定在我們的專案中哪些概念是合理的，以及我們如何在整個過程中利用自動化。我在訓練中結合了理論和實踐。下面是一些練習：

• 如何編寫Gherkin陳述—給定/當/那麼 (Given/When/Then：GWT)
• 一個好的使用者故事的關鍵屬性是什麼?
• 演示了我們的自動化框架，包括它是如何工作的，以及它是如何構造的。還有關於如何編寫簡單的自動化測試程式碼作為團隊的練習。在研討會之前，一個團隊成員和我修改了我們的自動化框架，以與ATDD方法一致。我們在我們的自動化框架中使用了帶有Java和Appium的外掛。

 

來源

步驟2 -增加可見性。

當一個專案在多個sprint中執行時，很容易忽略需要遵循的不同流程。因此，關鍵是要讓整個團隊都能看到目標、目的和期望。

當我們開始使用ATDD時，我只是簡單地寫下每一個需要在白板上執行的日常流程，將它放置在我們團隊日常召開站立會的地方。在每個使用者的故事中，我新增了一個待辦事項清單，都完成之後才能認為這個故事完全完成了。這樣，對於需要遵循的ATDD過程就沒有歧義了。其中一個清單專案是啟動會議，在此期間，開發人員、測試人員和業務人員作為一個團隊討論了需求，確定哪些需求可以自動化，並以GWT格式概述了這個故事的驗收標準。另一個檢查表項是QA-Dev（質保–開發)接力，開發人員通過快速演示或討論向測試人員展示需求是如何完成的，以及哪些單元測試是作為故事的一部分編寫的。通過這種接力，測試人員瞭解了哪些區域沒有被單元測試覆蓋，並且對實現的特性有了更好的理解，從而會有更好的測試覆蓋率。清單上的專案有時是顯而易見的，但清晰說明有利無害。其中包括，確保所有與故事相關的缺陷已關閉;另一個是業務代表在觀看演示後的最終認可，確保這些功能是滿足了先前設定的要求和期望。

我們還開始擁有了一名「過程鷹」。這是一個單獨的團隊成員;它可以是scrum管理員、專案經理或者任何可以確保團隊遵循這個過程的人。在我的這個案例中，它是團隊中的另一個高階測試人員;他和我經常提醒每個人在所有的會議上遵循ATDD流程，包括站立會、計劃會、回顧會和其他團隊會議。

步驟3-迭代總結和反饋。

在實現任何敏捷方法(包括ATDD)時，持續反饋迴圈是至關重要的。與整個團隊進行每週或兩週的回顧會議是瞭解過程中哪些部分實際上會有利於團隊，哪些部分可能需要修改。正如我們已經知道的，一些對團隊沒有幫助的事情會浪費時間和精力。就像《吃掉那隻青蛙》的作者布萊恩·崔西所說的：在更短的時間內，停止拖延和做更多事情的好方法是：「最浪費時間的一種做法就是做一些根本就不需要做的事情。」

在當今資訊科技時代，組織不能浪費時間和精力在無效的方法上;相反，我們需要精簡和有效的過程。這與 有效學習 的精益創業原則有關：構建、度量、學習週期。

考慮到這一點，我開始每星期四與團隊A進行30分鐘的會議，檢查團隊是如何執行的新流程。用這種辦法可以很好地根據團隊的反應判斷需要做出哪些改變。這種會議是在兩週迭代結束後的回顧會議上單獨舉行的。這種方法帶來了團隊的持續反饋，使我們能夠做出即時有效的改變。反饋並不僅僅來自每週的流程檢查;每日站立會議也被證明是一個寶貴的資訊來源。單體團隊成員補充討論發現的與此過程相關的危險訊號，我們能夠在它們影響團隊其他成員之前立即解決這些問題。

總結

由於採用了ATDD實現週期，團隊A開始在團隊士氣、協作和需求方面看到了相當大的差異。

團隊士氣

每個人都開始以團隊的形式工作，感到自己被賦予了權力。每個人都能從頭到尾掌握一個故事。他/她確保掌握了這個故事開展開發和測試工作所需的所有必要資訊。該團隊成員也確保了所有與故事相關的工作得以完成。最後，這個人負責在sprint結束時向所有利益相關者展示這個故事。這種能夠自主掌控的感覺極大地提升了團隊的士氣。

協作

啟動會將業務人員、開發人員和測試人員聚集在一起，以開發對使用者故事的共同理解。在質保與開發的對接在把構建包發到測試環境之前就完成了，幫助開發人員和測試人員明白測試應作為故事的一部分來完成，並對實現的特性有了更好的理解。因為整個團隊都擁有了自動化的所有權，而不僅僅是測試人員，所以這方面的自動化的可視性也提高了。最後，在規劃會上，整個團隊一起討論這個故事，從而產生更多的想法、問題和討論。更多的協作也帶來了更多的學習，團隊決定進行點對點的培訓加強互相學習，測試人員開始進行 結對的探索性測試 ，並且由不同的團隊成員組織了午餐交流會，討論關於技術的各種主題。所有這些都帶來了團隊更好的協作。

需求

我們以前的流程存在一個主要問題，那就是需求和範圍頻繁地變化。使用ATDD方法，一旦開發人員開始編寫一個故事，需求就會被鎖定。任何改變都必須與其他即將到來的故事放在一起，並新增到即將到來的迭代中。這減少了開發人員和測試人員的工作量，並防止了涉眾對已完成的特性抱有不切實際的期望。

在看到上述所有改進後，B團隊也開始實施ATDD。因此，在常規的實驗和反饋之後，最初的整個團隊都使用了這種方法。

結論

我建議使用ATDD的方法，它與「 左移正規化 」是一致的，也就是在SDLC中所說的開發和測試儘早介入。當我們開始在SDLC開始編寫自動化測試時，它為自動化帶來了更多的可視性，這反過來又增加了團隊內部的協作。

 

來源

記住，ATDD不是一個「放之四海而皆準」的解決方案。在我的專案中，敏捷方法是最有意義的，但是在團隊中有很多其他的方法來改進流程。我使用這種方法是因為關注更好的驗收測試，但更重要的是它強調協作。協作部分是這種方法的一個組成部分，我認為它是最有價值的。

關於作者

Raj Subramanian曾是一名開發人員，他後來激情滿滿地轉向測試。Raj目前是 Testim.io 的一名開發者傳道師，他們為Netapp、Swisscom、Wix和Autodesk等企業提供穩定、自修復的基於ai的測試自動化。他還為各種客戶提供移動培訓和諮詢服務。他通過在會議上發言、撰寫文章、寫部落格、在youtube上釋出視訊以及直接參與各種與測試相關的活動，對測試社羣做出了積極的貢獻。他目前居住在芝加哥，可以通過 [email protected] 聯絡他。這是他的 網站 和 推特賬號 。他有關測試、領導力和生產力的視訊可以在 這裏 找到。

 檢視英文原文： A Quick Guide to Implementing ATDD