《敏 捷 教 練：如何打造優秀的敏捷團隊》—9.4 缺陷管理

9.4? 缺陷管理

團隊若想在迭代結束時“完成”所有的故事，就得好好想想如何處理迭代中發現的缺陷。很明顯，如果某個故事測試運行失敗，肯定得先修復它，然后故事才能算作“完成”。但是，如果缺陷引出了規劃會議時尚未想到的新的故事測試呢？團隊是應該在當前迭代修復這個缺陷，還是推到后一個迭代再處理？

和他們一起思考對策，以此輔助他們決定下一步該做什么。如果軟件已經交付實現了用戶故事的主要價值，就可以推遲修復缺陷。但是，如果留著問題不解決會妨礙某個近在咫尺的發布，就得馬上修復。由于這是計劃之外的工作，修復缺陷可能會使團隊陷入無法完成其他故事的境地。提醒團隊，如果他們擔心這種事情的發生，就去跟客戶談談現在的情況。

如下實例展現了一場典型的交談，發生在開發人員檢查他們是否已“完成”的時候。

尚未全部完成

“耶！”Rebecca樂開了花。“我終于做完輪轉故事了，現在就可以用。”她環顧四周，伺機炫耀一把。“Larry，你忙不？我需要你來測試一下。”

“當然。我先做完手頭這個測試，然后就去幫你。”Rebecca拿了一只蘋果邊吃邊等Larry。

“好了，你想要我做什么呢？”他一邊問，一邊轉動椅子，以便可以看見Rebecca的屏幕。

她很驕傲地說：“我已經做完書籍輪轉了，”。

“真棒。那我們一塊來看看吧。”

Rebecca打開網站，打開“新書單”頁面。一個立體的新書名單開始輪轉。

Larry問道：“我喜歡！怎么停在自己想要的書那里呢？”Rebecca點擊一本書，輪轉停止。

“可以用鍵盤操作么？”Rebecca嘗試敲擊了幾個鍵，沒反應。

“看來不行，我得琢磨琢磨怎么做。”她拿起面前的一張黃色索引卡，記了下來。

第二天，Rebecca解決了問題，Larry挑選集成服務器上部署的干凈版本進行測試。

“Rebecca，結果很好。不過還有些細節我想讓Amanda看看。”Larry喊了一聲，“嘿，Amanda，有時間嗎？”

“當然，不過你得快點，我3點鐘還要開個會。”她笑了笑，走到Larry的桌旁。Rebecca也加入了他們。

“我剛剛測完了Rebecca開發的輪轉。但我想讓你也看看我發現的一些情況。”Larry轉過去對Rebecca說，“Rebecca，不如你跟Amanda演示一下它是怎么用的？”

Rebecca打開新的書籍列表頁，演示給Amanda看那個輪轉。“看著真不錯，我喜歡！”Amanda說。

“是啊，看起來挺棒的。只是有一些小問題。”Larry伸手把鼠標拿了過來。“如果書沒有圖片，就會顯示成這個樣子。”Larry轉動輪轉，停在了很后面的位置。

“噢，那可不好。”Amanda皺起了眉頭。

“我們該怎么處理書籍沒有圖片的情況呢？估算故事時我們可沒想到這一點。”Rebecca說道。

“輪轉里先別顯示它們。然后我們再給那些書弄一張預留圖片。”Amanda做出了決定。Rebecca把它作為黃色索引卡上的一個任務記了下來。

“較長的書名在IE6中無法正確顯示。”Larry演示了一遍。

Larry又找到一個問題，Rebecca看起來有點小失望。“這個改起來挺棘手的，它在Firefox和Safari瀏覽器上都能正常顯示。”

“書名得有多長才算超過了上限？”Amanda問道。

“呃，看來看去我也就只見過一兩次。再看看吧。”Larry選中一個長書名，將它復制到編輯器里統計字數。“98個字符，看起來它在第95個字符的地方被截斷了。”

“Rebecca，你能查一查有多少本書的書名是超過95個字的嗎？”Amanda瞟了一眼手表，問道。

“我看看，”Rebecca說道，趕緊寫了一條數據庫查詢。“四本。”

“四本？總共多少本？”

“剛過5000本。”

“還行，我能忍受。這個迭代就別急著修復了。你還是先做那個推薦引擎故事吧。”

“好。我先修復缺圖片的問題，明天可以開始做推薦故事。”Rebecca眉開眼笑，如釋重負。

“太棒了！好吧，我得趕緊過去開會了。”Amanda抓住放在打印機上的一份報告，補充說道，“我要是能趕回來就找你們倆一起吃飯，咱們去試試那家新開發的果汁吧。”

上述故事中，團隊使用了黃色卡片來記錄缺陷，放在板上很顯眼，一看就知道有缺陷需要修復。你會發現，測試人員只跟客戶討論了邊界用例。客戶做出決定，推遲修復書名過長帶來的顯示問題，因為她發現這只影響到很少的幾本書而已。為避免陷入缺陷追蹤的灰色地帶，這個故事并未闡述記錄缺陷的方法。

標出失敗的測試

阻止測試人員，別讓他們把缺陷報告“埋葬”到缺陷追蹤器里。相反，鼓勵他們使用團隊板來標記出失敗的測試，讓整個團隊都能看到。這樣一來就很清楚了，團隊得先解決這些問題才能完成此故事。

通過郵件報告缺陷

Rachel

我剛剛合作過的一個團隊，有個測試人員總是用郵件交流她所發現的問題，同時還抄送給QA部門的老大。開發人員非常希望她能先跟大伙談過之后，再把郵件發給團隊外的人，尤其是開發人員忙于編碼根本沒時間經常檢查郵件。她的解釋是她不想打擾大家，而她也讓QA經理了解情況是為了證明團隊需要增加一名測試人員。

很不幸，開發人員開始忽視她的存在，沒有問過她就直接往現場環境上部署變更。這簡直就是火上澆油！QA的老大召集整個團隊，試圖通過一個工作坊來處理此狀況。

團隊共同約定，從今往后，測試人員如果發現了故事的問題，要用彩色卡片在團隊板上標記出來。開發人員會在卡片上標出已修復版本的版本號。通過這種方式，測試人員不會打擾開發人員，也不會把問題埋葬在郵件中。

安東尼·馬卡諾(Antony Marcano)警告我們，缺陷追蹤器會變作一個隱藏列表(參見下面的補充材料)。我們喜歡他的建議，把延遲的缺陷當作新的故事，放入用戶故事backlog[1]留給后續迭代。不需要單獨使用缺陷追蹤工具，雖然有一個也不錯，但可以以電子形式存儲缺陷的細節，例如截屏。

隱藏的backlog——Antony Marcano，testingReflections

我曾是一個成立已久的團隊的其中一員，該團隊每一兩周都能交付可工作軟件。迭代中，只要覺得故事已接近完成，我們就會進行探索式測試。一旦發現缺陷，我們就會及時記入缺陷追蹤系統。有時我們會直接修復缺陷，有時也會交由客戶來決定。

我們使用測試驅動開發(TDD)，也即在每次修復缺陷之前，我們會先寫一個自動化的故事測試來重現它。由此我想到，這些缺陷其實就是我們之前沒有想到的那些故事測試。

我們必須在缺陷追蹤系統中填寫缺陷報告，在自動化測試中又重復一遍相同的信息，這挺浪費時間的，大家都很沮喪。缺陷追蹤僅僅幫我們解決了一個問題，即追蹤狀態和干活的人。

我意識到，如果缺陷報告近似于故事測試，當然可以把一個或多個缺陷概括為一個新的用戶故事。我們知道怎么管理用戶故事！就在那一刻，我發現這個事實，我們其實有兩個backlog！一個是由用戶故事記載的尚未實現的行為backlog，另一個是缺陷追蹤系統中記錄的缺失行為的backlog！缺陷追蹤系統其本質就是一個隱藏backlog。

維護這些孤立的backlog會產生副作用，我們區別對待了缺陷和故事。我們并未使用相同的方式，或是在同一時間對它們進行優先級排序。我曾見過團隊專門預留出一部分時間用于修復之前迭代的缺陷，但并未和當前迭代的故事合并進行優先級排序，或者無視backlog中價值更高的故事，預留時間修復所有缺陷。按照這種方式，我們預留時間進行缺陷修復，無視其影響，有時這會導致我們選擇一個比新故事價值更低的缺陷進行修復,反之亦然。

如今在新項目中，只有需要時我們才會在缺陷追蹤系統中新建一個項目。我已經有很長時間沒有發現這種需求了。

記住，條條大路通羅馬。我們也曾見過一些團隊，為了免于創建隱藏的backlog，他們就把所有的缺陷和故事統統放進缺陷追蹤器(例如Trac[1])，并把它用作規劃工具。此方法需要客戶也得懂技術，要能投入時間學習新工具，而不是只會用電子表格之類較為熟悉的辦公工具。

找到問題的根源

每次找到缺陷，都是一次流程改進的好機會。鼓勵團隊找出導致缺陷的原因，思考是否可以在下一迭代中避免它的發生。每找到一個缺陷，都可以討論，也可以等到回歸會議時再集中探討。在第10章“用測試來驅動開發”中，我們會進一步談談開發人員如何改進代碼質量并減少代碼缺陷。

敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。