隨著發(fā)布時間的臨近，團隊肩膀上的壓力越來越大。因為專注于下一次迭代，開發(fā)人員開始忘記周末是休息時間。管理人員的壓力可能會更重。唯一阻礙我們前進(jìn)的事情是測試……測試的進(jìn)展不夠快。

在開發(fā)周期的最后階段，很容易看到事情明顯放緩，至少從某個角度來看。

三件主要的事情

平均每天，測試人員花費大量的時間在三個不同的活動上——test，bug和setup，即TBS。

T

Testing time——是我們要做的事情，也是很多混亂被引入的的地方。當(dāng)我們談?wù)撐覀冋诠ぷ鞯膬?nèi)容時，大多數(shù)測試人員用“我正在測試新的報告功能”或“我正在構(gòu)建來自于最后沖刺用于批量加載功能的自動操作”來報告狀態(tài)。這些聲明是準(zhǔn)確，肯定的，但他們也可以隱藏了所有你不得不做的其他工作。如果我們想獲得更具體的內(nèi)容，那么我們可以減少測試時間，縮短到只花費在評估軟件上的時間。當(dāng)我在看文檔和談?wù)摦a(chǎn)品有關(guān)的新變化時，是為了幫助設(shè)計測試，這就是測試時間。當(dāng)我工作在軟件上時，我的探索和測試，也是測試時間。

B

Bug——當(dāng)我們發(fā)現(xiàn)bug時，我們會從主要工作（需要測試的內(nèi)容）切換到一些由于問題造成的意外情況上。如果問題不存在，那么我們就不需要花費時間去重現(xiàn)，去探索知道問題是局部的還是更大問題的一個癥狀，也不需要為了修復(fù)去文檔記錄和支持。發(fā)現(xiàn)一個bug破壞了測試流：停止工作，停止測試速度，如果你用那種方式考慮事情的話。當(dāng)我在測試時，發(fā)現(xiàn)了一些有趣的東西，一般我做的第一件事就是，嘗試重建這種情況。這里就是我做的瞬間放緩的地方，因為我需要追溯我的步驟。有時，bug簡單，那么我可以馬上重建它，而當(dāng)bug狡猾的時候，那我就需要時間來搞清楚。在研究bug后，還要報告此事。無論你是很幸運有一個演示就足夠了，還是必須在一個跟蹤系統(tǒng)中做一個全面的報告，都是需要時間的。Bug阻礙了測試活動前進(jìn)的腳步，并且我們通常不知道它們會在什么時候突然出現(xiàn)。

S

Setup——不像工作于bug時創(chuàng)建測試的start-stop經(jīng)歷，設(shè)置活動在一開始就限制了工作流，就像高速上的匝道一樣。設(shè)置是我在執(zhí)行測試前不得不做的一切事情。在最簡單的情況下，我用工具，例如Excel來創(chuàng)建數(shù)據(jù)，要么使用腳本要么自己加載到軟件中。這種設(shè)置非?？欤恍枰獛追昼?。在圖表的另一端則需要幾小時或幾天的設(shè)置活動。在有一個案例中，我和一個開發(fā)人員工作了一兩天才創(chuàng)建了數(shù)據(jù)，然后打包到SQL腳本中，在我們可以做任何有意義的測試之前，得到填充了數(shù)據(jù)的系統(tǒng)。

在你第一次測試一個新的東西時，很難繞過設(shè)置成本。如果你打算將來重新測試，那么有時測試管理工具可以，通過運行安裝腳本或為工作在那個領(lǐng)域的下一個人存儲特殊信息，幫助降低成本。

我們通常不會去關(guān)注時間都花在了哪里，并且?guī)缀鯊膩頉]有均勻分配時間。Test Bug Setup更像是一個三邊的蹺蹺板。當(dāng)我花了大量時間在設(shè)置數(shù)據(jù)上時，那么可能可用到測試上的時間就會變少，而用來報告發(fā)現(xiàn)的問題的時間就更少了。如何正確地安排這些時間是需要平衡的。

如果你想知道為什么測試要花這么長時間，那么就看一看你的員工工作的所有未測試的其他活動。那項工作可能對項目而言是至關(guān)重要的，是為了添加信息，促進(jìn)測試，但你可能會驚訝地發(fā)現(xiàn)它只是嵌入在表面之下。

譯者@碼農(nóng)網(wǎng)?– 小峰

譯文鏈接：http://www.codeceo.com/article/why-your-project-take-so-long.html

英文原文：Why Is Your Project Taking So Long?