怎樣看待活文檔“ATDD”---記敏捷中國2012 open space

爲什麼要有一份活文檔?
在現實中有太多這樣的情形:新介入一個項目,老人會丟過來一堆的文檔或者鏈接地址,並告訴你說,這些是與這個項目相關的一些文檔資料,這些資料裏有些內容是已經過時了的,項目有些最新的需求還沒人補充,先借鑑着看吧,不看文檔還好一點,看了文檔更暈。產品經理悶着頭吭哧吭哧寫了半個月的需求說明,然後招集大家開會,在會上打出投影對幾十頁的需求說明一個字一個字的過,產品經理在上面講的口吐白沫,下面的聽會人員昏昏欲睡,4個小時過去了,文檔終於過完了,開發工程師按進度完成開發任務了,提交測試,測試人員看着實現出來的功能直撓頭,這不對呀,叫來產品經理三方對質,產品經理說,我寫的需求說明要表達的意思是這樣這樣這樣的,不是現在這個樣子的,聽完這句話,開發人員直接口吐白沫暈倒過去,產品經理嘆氣搖頭“唉,這些東西我在那天的需求評審會上都說過的,怎麼就不記呢,需求又有變更了,我還得抓時間把文檔修改一下”,合上電腦悄然離開,揮一揮衣袖不帶走一片雲彩。
ATDD是什麼?
ATDD即驗證測試驅動開發,文鄒鄒的定義是“
在準備實施一個功能或特性之前,首先團隊需要定義出期望的質量標準和驗收細則,以明確
而且達成共識的驗收測試計劃(包含一系列測試場景)來驅動開發人員的TDD實踐和測試人員的測試腳本開發
”。
ATDD的開發過程:
簡單來說,有新的需求時,產品、開發、測試三方坐在一起,先由產品人員講解需求,解答開發與測試提出的疑問,三方對需求達成共識,即三方對需求的看法和達成的標準是一致的;
接下來,開發人員根據已有的設計、代碼等設計開發策略,測試人員分析並列出驗證的場景和標準;
開發人員與測試人員共同評審測試人員設計的驗證測試場景和標準,就此達成共識;
開發人員就此設計單元測試用例,測試人員設計驗收測試用例及測試數據;
開發人員完成開發,提交測試前先運行單元測試和已達成共識的驗證測試,驗證已完成的功能是否準確;
提交測試後,測試人員進行驗證,就發現的問題向開發人員反饋;
如果想引入工具,現已有基於FitNesse的驗收測試驅動開發 ,這個鏈接地址介紹的簡單易懂,沒必要再把人家的東西原樣的搬過來了。簡單說,就是在wiki中寫出需求並舉實例(也許應該說成是實例化需求吧),這些實例的列表可以通過某些手段直接與代碼接口相連,代碼完成後,但可“運行”這份需求文檔來驗證實現的是否符合標準。
ATDD的好處:
1.減少因爲溝通不一致,而返工的時間浪費;
2.提高交付產品的質量;
3.可快速進行自動化測試;
4.提升個人在團隊中的責任感; 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章