為什么你的項目要花這么長時間?
隨著發布時間的臨近,團隊肩膀上的壓力越來越大。因為專注于下一次迭代,開發人員開始忘記周末是休息時間。管理人員的壓力可能會更重。唯一阻礙我們前進的事情是測試……測試的進展不夠快。
在開發周期的最后階段,很容易看到事情明顯放緩,至少從某個角度來看。
三件主要的事情
平均每天,測試人員花費大量的時間在三個不同的活動上——test,bug和setup,即TBS。
T
Testing time——是我們要做的事情,也是很多混亂被引入的的地方。當我們談論我們正在工作的內容時,大多數測試人員用“我正在測試新的報告功能”或“我正在構建來自于最后沖刺用于批量加載功能的自動操作”來報告狀態。這些聲明是準確,肯定的,但他們也可以隱藏了所有你不得不做的其他工作。如果我們想獲得更具體的內容,那么我們可以減少測試時間,縮短到只花費在評估軟件上的時間。當我在看文檔和談論產品有關的新變化時,是為了幫助設計測試,這就是測試時間。當我工作在軟件上時,我的探索和測試,也是測試時間。
B
Bug——當我們發現bug時,我們會從主要工作(需要測試的內容)切換到一些由于問題造成的意外情況上。如果問題不存在,那么我們就不需要花費時間去重現,去探索知道問題是局部的還是更大問題的一個癥狀,也不需要為了修復去文檔記錄和支持。發現一個bug破壞了測試流:停止工作,停止測試速度,如果你用那種方式考慮事情的話。當我在測試時,發現了一些有趣的東西,一般我做的第一件事就是,嘗試重建這種情況。這里就是我做的瞬間放緩的地方,因為我需要追溯我的步驟。有時,bug簡單,那么我可以馬上重建它,而當bug狡猾的時候,那我就需要時間來搞清楚。在研究bug后,還要報告此事。無論你是很幸運有一個演示就足夠了,還是必須在一個跟蹤系統中做一個全面的報告,都是需要時間的。Bug阻礙了測試活動前進的腳步,并且我們通常不知道它們會在什么時候突然出現。
S
Setup——不像工作于bug時創建測試的start-stop經歷,設置活動在一開始就限制了工作流,就像高速上的匝道一樣。設置是我在執行測試前不得不做的一切事情。在最簡單的情況下,我用工具,例如Excel來創建數據,要么使用腳本要么自己加載到軟件中。這種設置非??欤恍枰獛追昼?。在圖表的另一端則需要幾小時或幾天的設置活動。在有一個案例中,我和一個開發人員工作了一兩天才創建了數據,然后打包到SQL腳本中,在我們可以做任何有意義的測試之前,得到填充了數據的系統。
在你第一次測試一個新的東西時,很難繞過設置成本。如果你打算將來重新測試,那么有時測試管理工具可以,通過運行安裝腳本或為工作在那個領域的下一個人存儲特殊信息,幫助降低成本。
我們通常不會去關注時間都花在了哪里,并且幾乎從來沒有均勻分配時間。Test Bug Setup更像是一個三邊的蹺蹺板。當我花了大量時間在設置數據上時,那么可能可用到測試上的時間就會變少,而用來報告發現的問題的時間就更少了。如何正確地安排這些時間是需要平衡的。
如果你想知道為什么測試要花這么長時間,那么就看一看你的員工工作的所有未測試的其他活動。那項工作可能對項目而言是至關重要的,是為了添加信息,促進測試,但你可能會驚訝地發現它只是嵌入在表面之下。
譯者@碼農網?– 小峰
譯文鏈接:http://www.codeceo.com/article/why-your-project-take-so-long.html
英文原文:Why Is Your Project Taking So Long?
資源互換,聯合推廣,渠道合作,實物贊助。需要資源和渠道合作的朋友加微信公眾號btcm888888,獲取更多信息,必拓傳媒首字母+六個8