作爲開發人員，我們應該遵守這樣一句話：“質量不是來自檢查，而是來自生產過程的改進。”
——愛德華·戴明
太多的組織將任何未編碼的東西視爲一次性的。很明顯，測試是必不可少的，但我們一次又一次地發現，團隊將測試自動化和相關材料視爲二等公民。測試是用戶行爲的文檔，與產品組織產生的需求密不可分，並在虛擬層面與用於創建功能的代碼相連。
如果它提供了價值，就應該對它進行版本化、維護、照顧和尊重，就好像它是產品本身的核心功能一樣。這應該包括測試用例規範、設計和技術文檔以及錯誤報告。
大多數人可能會認爲，在一個功能上花的時間越多，就需要花越多的時間來完善、完善、測試和探索它。與直覺相反，這適合“舊世界”風格的開發，有一個測試環境、一個階段環境，以及圍繞用戶將如何與之交互的許多宏大假設。
這些法則試圖將SDLC（系統生命週期）引入雲計算世界：微小的、漸進的變化，在推廣到整個世界之前，先向有限的受衆推廣。“鍵盤在10分鐘內完成生產”——這會帶來更快的反饋、更少的逃脫和更高的信心。以下是編碼新世界的10大法則。
1.人人皆測試
團隊的每一位成員，無論使用什麼流程，無論生產什麼產品，無論哪個行業——每個人——都對產品的質量負責。產品、工程、測試，甚至周圍的功能：客戶支持、銷售、營銷、業務開發、早期訪問測試版客戶、高管——每個人都在測試。
2.度量風險而非覆蓋率
假設團隊甚至可以就“完美”的工作定義達成一致，那麼僅僅追求完美就會導致注意力從最重要的事情上轉移：關鍵缺陷轉移到生產中對業務的風險。在你開始擔心所有功能的全面覆蓋之前，先癡迷於對你的業務最關鍵的六個用戶流。
3.測試的是“金錢”想要什麼
每個業務、每個部門和每個團隊都部署了一組核心功能，這些功能對收入的影響比其他功能更大。或者，每個團隊都必須維護一組影響較小但仍然必要的功能。在考慮其他因素之前，將測試工作重點放在影響收入的部件上。對於電子商務，將結賬流程優先於用戶配置文件。對於財務，優先考慮安全和資金處理工作流程，而不是信息頁面。
4.廣度比深度更重要
淺層測試產品的所有區域比深層測試產品的某些區域更重要。業務邏輯的深度、多元組合旨在找到最模糊的邊緣案例：這可能會在其他高優先級領域遺漏更明顯的缺陷。一旦達到了廣度，那對某個特定功能的深度是多少？請參考法則2。
5.唯一完美的信號是用戶的信號
在你的用戶與你的軟件交互之前，你所做的一切都是理論性的。
測試就是模型。它們是基於從過去用戶行爲中獲得的信息的用戶行爲的近似值。我們從測試中得到的信號可能因環境、測試本身的邏輯缺陷、無意識的偏見，甚至之前模型中的錯誤數據而存在缺陷！
瞭解用戶使用軟件時會發生什麼的唯一方法是觀察用戶使用軟件後會發生什麼。生產分析的用戶旅程應與測試覆蓋率相關聯，以評估測試策略的有效性。
此外，考慮到用戶體驗中包含的元素甚至不會被視爲bug，也可能不會反映在分析中。當構建變爲綠色時，並不意味着就是工作的結束。
6.代碼在可測試（並經過測試）之前是不完整的
可測試性是對代碼的各個部分進行檢測的行爲。如果不允許對這些信號進行輪詢和解釋，很難判斷正確的行爲。這導致了不成比例的額外工作，這增加了發佈週期的時間，並將焦點從客戶體驗上轉移開。時間將會扼殺信心。
7.每項測試都應導致明確的行動
如果不知道當測試失敗時該怎麼辦（無論是從測試的角度還是從產品的角度），那麼測試就沒有提供價值。這通常是由於測試步驟太多，或者產品沒有提供足夠的失敗信息（包括沒有充分的可測試性，參照法則2。）
8. 始終測試高層級
軟件測試有“層”（從高到低）：生產、UAT、功能、集成和單元。
高層測試對於強制不同團隊開發的不同組件之間的交互至關重要，但邊緣案例的細節可能會向下移動到較低層。這些較低層測試具有較少的依賴性，避免了昂貴的管道配置/編排，並且運行速度比較高層測試更快。
例如，UI測試應該僅用於確定用戶界面是否能夠呈現API的輸出。如果通過同一個UI重複測試業務邏輯，則應該將這些測試中的大部分“向下”移動到API層。
9.從不鏈接測試
所有測試都應在不考慮任何其他測試狀態的情況下執行。測試數據的管理應確保每個測試都生活在自己的獨立場景中，並且不能被另一個測試更改。測試應該是原子化的、自主的。
10. 首選最緊密的反饋迴路
所有測試都是反饋迴路。他們從特定的角度貫穿產品，並向特定的人或團隊提供反饋。最嚴密的反饋迴路是儘可能多地切斷以測試所討論的特定操作的迴路。測試一個比必要的更寬的循環會引入一些變量，這些變量可能會混淆你從測試中得到的信號。
寫在最後
這十條法則並不完整，測試領域還有很多限定守則，而且使用這些法則時的上下文環境也很重要。也許某次測試會打破一兩條法則，那也無妨，不必把它們奉爲金科玉律，重要的是尋求持續改進，而非特定一次的完美。