在構(gòu)建高質(zhì)量產(chǎn)品時，作為質(zhì)量保證，我們可以從“質(zhì)量是什么？”這一問題開始。它經(jīng)常在學(xué)術(shù)上，哲學(xué)上或ISO定義上得到回答。但我想首先看看我們都知道的產(chǎn)品示例：一個松餅。

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

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

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

過程中的變化如何提高質(zhì)量

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

在第一步（“分析”），我們計劃創(chuàng)造價值。我們?yōu)榇藢懥艘粋€故事，然后我們把它放在“積壓”中 - 所以沒有立即對它做任何事情。換句話說：我們在浪費時間。在最好的情況下，分析的故事在實施時仍然是最新的。通常情況下，故事已經(jīng)過時了。在下一步（“開發(fā)”）中，我們將計劃值添加到產(chǎn)品中。之后故事又在一個流程步驟中等待（“等待質(zhì)量保證”），所以在這里，我們只是在浪費時間。該團(tuán)隊等待質(zhì)量分析師（QA）審核預(yù)定價值并將其交付給用戶（“質(zhì)量保證”）。

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

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

分析師的協(xié)同作用：業(yè)務(wù)和質(zhì)量如何協(xié)同工作

要真正與業(yè)務(wù)人員（業(yè)務(wù)分析師，產(chǎn)品負(fù)責(zé)人或產(chǎn)品經(jīng)理）合作，了解所有相關(guān)的觀點非常重要：  我們的業(yè)務(wù)分析師（BA）通常非常積極地快速發(fā)布軟件，因為（軟件）的后期發(fā)布產(chǎn)品導(dǎo)致更高的成本和更低的收入。

另一方面，質(zhì)量保證的工作是確保向市場推出一種可靠且?guī)缀鯖]有錯誤的產(chǎn)品。 

挑戰(zhàn)是在速度和質(zhì)量之間找到平衡點。為此，NASA曾經(jīng)分析了錯誤成本的確切位置。 

圖1：錯誤成本

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

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

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

主動

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

為了從一開始就提高質(zhì)量，我們嘗試將一個簡單的規(guī)則應(yīng)用于所有團(tuán)隊：每次提交都要進(jìn)入生產(chǎn)階段。

設(shè)置此規(guī)則可提高質(zhì)量：當(dāng)QAs不再是可能出錯的最后監(jiān)護(hù)人時，開發(fā)人員會花更多時間確保他們的測試涵蓋最重要的事情。由于質(zhì)量保證是測試的專家，開發(fā)人員和質(zhì)量保證之間的推拉關(guān)系被這一新規(guī)則所逆轉(zhuǎn)。之前，門票已被推送到QAs進(jìn)行測試。現(xiàn)在，開發(fā)人員正在向QA詢問有關(guān)如何最好地構(gòu)建測試的建議 - 特別是在實現(xiàn)之前。

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

我們的團(tuán)隊設(shè)置不再需要它。通過30分鐘或更短的發(fā)布周期，我們可以快速響應(yīng)生產(chǎn)問題而無需修補(bǔ)程序或分支。我們甚至不再需要回滾策略。

該真正有趣的問題是如何設(shè)計監(jiān)控，以便您可以更早地發(fā)現(xiàn)生產(chǎn)中的問題。這至少包含應(yīng)用程序錯誤數(shù)量的可視化，以及服務(wù)器或數(shù)據(jù)庫響應(yīng)時間。如果你想達(dá)到一個非常專業(yè)的水平，你可以考慮全自動檢測異常。

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

創(chuàng)造接受和從錯誤中吸取教訓(xùn)的文化提供了最終的質(zhì)量提升

每個團(tuán)隊都會犯錯誤，這是人性，而且很好，因為我們從錯誤中吸取教訓(xùn)。作為QAs，我們非常關(guān)注錯誤的風(fēng)險和影響，它們可以幫助團(tuán)隊在安全的環(huán)境中快速犯錯 - 從而使團(tuán)隊能夠非常快速地學(xué)習(xí)新事物。這不僅增加了團(tuán)隊的安全性和信任度以及軟件的質(zhì)量，而且?guī)缀跻馔獾匾彩菆F(tuán)隊的創(chuàng)新潛力。

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

但滑倒并不是配對的唯一動機(jī)。你知道當(dāng)你嘗試新事物并理解某些東西是如何工作時所擁有的“啊哈時刻”嗎？我們試圖讓團(tuán)隊盡可能輕松地通過“嘗試”（=故意挑釁錯誤）來體驗這樣的時刻 - 并在對話中談?wù)撍?/p>