在構建高質量產品時，作為質量保證，我們可以從“質量是什么？”這一問題開始。它經常在學術上，哲學上或ISO定義上得到回答。但我想首先看看我們都知道的產品示例：一個松餅。

什么品質會使松餅成為高品質的松餅？當然巧克力灑在上面！讓我們直接進行質量保證的第一次比較：正如巧克力在烘焙后散布在松餅上一樣，許多團隊在編程后才開始關注軟件的質量。兩種情況下的問題：松餅（軟件）中沒有巧克力（質量）。

在本文中，善微科技希望了解如何在軟件開發中盡早提高質量意識的方法和流程，或者換句話說，如何將巧克力直接烘焙到松餅中。

正如您可能猜到的那樣，這將大大增加常規“QAs”的工作范圍，從而使我們從“質量保證”角色中脫穎而出，成為真正的“產品質量專家”。

過程中的變化如何提高質量

如果我們仔細研究一下典型敏捷團隊的流程步驟，我們就可以看到詳細信息。

在第一步（“分析”），我們計劃創造價值。我們為此寫了一個故事，然后我們把它放在“積壓”中 - 所以沒有立即對它做任何事情。換句話說：我們在浪費時間。在最好的情況下，分析的故事在實施時仍然是最新的。通常情況下，故事已經過時了。在下一步（“開發”）中，我們將計劃值添加到產品中。之后故事又在一個流程步驟中等待（“等待質量保證”），所以在這里，我們只是在浪費時間。該團隊等待質量分析師（QA）審核預定價值并將其交付給用戶（“質量保證”）。

作為QAs，我們對“積壓”專欄的影響很小，我們為什么要在團隊中有一個流程步驟，其中唯一發生的事情就是浪費時間？如果我們配對，刪除“等待QA”列會對團隊工作的速度和質量產生非常積極的影響它與另一個工具：工作進度限制。想法如下：如果沒有“等待QA”列，開發人員沒有余地留下一個故事，一旦實施完成，因此不能只是開始一個新的。因此，開發人員必須確保將故事傳遞給可用的QA。這種強制移交有助于直接溝通：QA從開發者那里獲得有價值的上下文; 并且開發者可以利用與QA的對話來檢查是否實際滿足了特定故事的所有接受標準。

我們在不同的項目和不同的環境中使用了這些限制。在一個案例中，我們能夠縮短從“分析”到“完成”的時間段，從13天到4天，沒有任何人必須“更努力”地工作而不會影響質量。由于開發中的故事不需要不斷更改上下文，因此可以更快地完成故事。“在制品”的限制對團隊的集中度產生了積極的影響，因此不僅對產品上市時間有影響，而且對產品質量也有影響。 

分析師的協同作用：業務和質量如何協同工作

要真正與業務人員（業務分析師，產品負責人或產品經理）合作，了解所有相關的觀點非常重要：  我們的業務分析師（BA）通常非常積極地快速發布軟件，因為（軟件）的后期發布產品導致更高的成本和更低的收入。

另一方面，質量保證的工作是確保向市場推出一種可靠且幾乎沒有錯誤的產品。 

挑戰是在速度和質量之間找到平衡點。為此，NASA曾經分析了錯誤成本的確切位置。 

圖1：錯誤成本

很容易發現錯誤成本爆炸的時刻：生產中。這不僅是因為服務器被稱為“生產”，而且還因為到達生產系統的錯誤很長，因此更加昂貴。但無論成本大幅增加背后的確切原因是什么，典型的反應是在投入生產之前徹底重新檢查所有內容。這些是我們的CI / CD系統中的自動化測試用例。

但是如果你仔細看一下圖表，那么在起草要求和分析故事時 - 而不僅僅是在測試時 - 盡早發現缺陷并從一開始就提供高質量似乎是最具成本效益的。

根據我的經驗，當QAs和BA實際上并排坐著時，這是最好的。當他們在需求上一起工作并在短期計劃會議中將他們一起呈現給團隊。通過這種方式，可以在實施之前與整個團隊共享有關需求的知識（包括“邊緣案例”和“悲傷路徑”）。質量保證可以確保最重要的“悲傷路徑”已經考慮用于實施，因此也自動測試回歸。通過這種方式，手動測試的工作量大大減少。與時間壓力下的代碼凍結測試相比，我們推出的產品質量要好得多，而且市場早得多。

主動

理想情況下，開發人員與QA一起工作，將回歸測試從單元測試級別一直到所需的端到端測試，并遵循測試金字塔的原則。但是，無論這些測試在設計時有多精細，它們總是在實施后執行。

為了從一開始就提高質量，我們嘗試將一個簡單的規則應用于所有團隊：每次提交都要進入生產階段。

設置此規則可提高質量：當QAs不再是可能出錯的最后監護人時，開發人員會花更多時間確保他們的測試涵蓋最重要的事情。由于質量保證是測試的專家，開發人員和質量保證之間的推拉關系被這一新規則所逆轉。之前，門票已被推送到QAs進行測試。現在，開發人員正在向QA詢問有關如何最好地構建測試的建議 - 特別是在實現之前。

第二大優勢是，您可以更靈活地在緊急情況下采取行動。通常，在經典版本管理中，您有一個如何執行發布的復雜計劃。如果出現問題，可以使用hotfix-cherry-pick-branch-release-process來繞過團隊中的大多數安全措施和質量控制。這聽起來并不特別值得信賴。

我們的團隊設置不再需要它。通過30分鐘或更短的發布周期，我們可以快速響應生產問題而無需修補程序或分支。我們甚至不再需要回滾策略。

該真正有趣的問題是如何設計監控，以便您可以更早地發現生產中的問題。這至少包含應用程序錯誤數量的可視化，以及服務器或數據庫響應時間。如果你想達到一個非常專業的水平，你可以考慮全自動檢測異常。

因此，我們發布的問題顯著減少，同時使用功能切換以非常可控的方式啟用新功能。我們不僅能夠快速為用戶提供新的價值，而且還能同時實現更高的質量。

創造接受和從錯誤中吸取教訓的文化提供了最終的質量提升

每個團隊都會犯錯誤，這是人性，而且很好，因為我們從錯誤中吸取教訓。作為QAs，我們非常關注錯誤的風險和影響，它們可以幫助團隊在安全的環境中快速犯錯 - 從而使團隊能夠非常快速地學習新事物。這不僅增加了團隊的安全性和信任度以及軟件的質量，而且幾乎意外地也是團隊的創新潛力。

我們非常密集地使用的一種方法 - 以及團隊不斷要求的QAs - 是結對編程。它特別有助于我們避免小滑倒 - 這有時會發生。有效的損害控制是兩個人的“配對”，主要是開發人員。

但滑倒并不是配對的唯一動機。你知道當你嘗試新事物并理解某些東西是如何工作時所擁有的“啊哈時刻”嗎？我們試圖讓團隊盡可能輕松地通過“嘗試”（=故意挑釁錯誤）來體驗這樣的時刻 - 并在對話中談論它！