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