1947 年，發現了第一個計算機 bug —— 被困在計算機繼電器中的飛蛾。

要是所有的 bug 都能如此簡單地發現就好了。隨著軟件變得越來越復雜，測試和調試的過程也變得更加復雜。如今，軟件 bug 的生命周期可能會很長，盡管正確的技術和業務流程可能會有所幫助。對于開源軟件，開發人員使用嚴格的工單服務和協作來查找和解決 bug。

確認計算機 bug

在測試過程中，發現的 bug 會報告給開發團隊。質量保證測試人員盡可能詳細地描述 bug ，報告他們的系統狀態、他們正在進行的過程以及 bug 是如何表現出來的。

盡管如此，一些 bug 從未得到確認；它們可能會在測試中報告，但永遠無法在可控環境中重現。在這種情況下，它們可能得不到解決，而是被關閉。

有些計算機 bug 可能很難確認，因為使用的平臺種類繁多，用戶行為也非常多。有些 bug 只是間歇性地或在非常特殊的情況下發生的，而另一些 bug 可能會出現在隨機的情況下。

許多人使用開源軟件并與之交互，許多 bug 和問題可能是不可重復的，或者可能沒有得到充分的描述。不過，由于每個用戶和開發人員也都扮演質量保證測試人員的角色，至少在一定程度上，bug 還是很有可能會發現的。

確認 bug 后，修復工作就開始了。

分配要修復的 bug

已確認的 bug 被分配給負責解決的開發人員或開發團隊。在此階段，需要重現 bug，發現問題，并修復相關代碼。如果 bug 的優先級較低，開發人員可以將此 bug 分類為稍后要修復的問題，也可以在該 bug 具有高優先級的情況下直接指派某人修復。無論哪種方式，都會在開發過程中打開一個工單，并且 bug 將成為已知的問題。

在開源解決方案中，開發人員可以進行選擇他們想要解決的 bug，要么選擇他們最熟悉的程序區域，要么從優先級最高的的開始。綜合解決方案，如 GitHub 使得多個開發人員能夠輕松地著手解決，而不會干擾彼此的工作。

當將 bug 設置為需要修復時，bug 報告者還可以為該 bug 選擇優先級。主要的 bug 可能具有較高的優先級，而僅與外觀相關的 bug 可能具有較低的級別。優先級確定開發團隊解決這些問題的方式和時間。無論哪種方式，所有的 bug 都需要先解決，然后才能認為產品已完成。在這方面，適當的回溯到優先級高的需求也會很有幫助。

解決 bug

一旦修復了 bug ，通常會將其作為已解決的 bug 發送回質量保證測試人員。然后，質量保證測試人員再次將產品置于其工作中，以重現 bug。如果無法重現 bug ，質量保證測驗人員將假定它已得到適當解決。

在開源情況下，任何更改都會被分發，通常是作為正在測試的暫定版本。此測試版本分發給用戶，用戶再次履行質量保證測試人員的職責并測試產品。

如果 bug 再次出現，問題將被發送回開發團隊。在此階段，該 bug 將重新觸發，開發團隊有責任重復解決該 bug 的循環。這種情況可能會發生多次，尤其是在 bug 不可預知或間歇性發生的情況下。眾所周知，間歇性的 bug 很難解決。

如果該 bug 不再出現，則該問題將被標記為已解決。在某些情況下，最初的 bug 得到了解決，但由于所做的更改，會出現其他 bug。發生這種情況時，可能需要新的 bug 報告，然后重新開始該過程。

關閉 bug

在處理、識別和解決 bug 后，該 bug 將被關閉，開發人員可以轉到軟件開發和測試的其他階段。如果始終找不到 bug ，或者開發人員無法重現 bug ，則該 bug 也將被關閉 —— 無論哪種方式，都將開始開發和測試的下一階段。

在測試版本中對解決方案所做的任何更改都將滾動到產品的下一個版本中。如果 bug 是嚴重的，則在下一個版本發布之前，可能會為當前用戶提供修補程序或修補程序。這在安全問題中很常見。

軟件 bug 可能很難找到，但通過遵循過程，開發人員可以使開發更快、更容易、更一致。質量保證是這一過程的重要組成部分，因為質量保證測試人員必須發現和識別 bug ，并幫助開發人員重現這些 bug 。在 bug 不再發生之前，無法關閉和解決 bug。

開源的解決方案分散了質量保證測試、開發和緩解的負擔，這往往導致 bug 被更快、更全面地發現和緩解。但是，由于開源技術的性質，此過程的速度和準確性通常取決于解決方案的受歡迎程度及其維護和開發團隊的敬業精神。

Rich Butkevic 是一個 PMP 項目經理認證,，敏捷開發框架認證（certified scrum master） 并且 維護 Project Zendo，這是供項目管理專業人員去發現、簡化和改進其項目成果策略的網站。可以在 Richbutkevic.com 或者使用 LinkedIn 與 Rich 聯系。