從負面測試中排除負面因素

---

誤解通常會導致測試人員對軟件“破解”的評價不高。開發人員和利益相關者可能會稱其為負面測試，但結果卻是更好的產品，而且都是積極的。

 測試人員是新軟件的第一批用戶，它們對于使其可用至關重要。最后，每個人都有提供最佳產品的相同目標，因此讓測試人員探索和發現新的錯誤始終是一件好事——發現的錯誤越多越好！在軟件開發生命周期的開始階段，通過鼓勵探索性測試，可以更早、更輕松地修復漏洞，從而更早地發現錯誤。

 當然，我發現的許多錯誤都與功能要求無關。性能問題是一個常見的例子。在大多數情況下，需求并沒有說明需要多長時間，但是測試人員可以很容易地判斷出什么時候不合適。如果我不耐煩地等待我們的軟件，那么我們的客戶也會。而且，當我們仍然可以修復它時，您是否愿意從我這里而不是從客戶那里聽到？

我們到底在測試什么？

早上8點30分，我們的產品經理走進我們的辦公室，問：“項目負責人在哪里？”

首席開發人員說：“他出去了。需要我們怎樣幫助你？”

“將數據庫從MySQL遷移到MariaDB的用戶故事的狀態如何？”

首席開發人員回答：“我們之所以延后，是因為MySQL主表的某些關鍵元素不容易遷移到MariaDB。”

產品經理的語氣立即變得更加清晰。“延后多少？幾天，幾周？”

我們的主要開發人員如實回答：“至少還有四天。”

房間里寂靜無聲。最后，產品經理說：“你能告訴項目負責人來我辦公室嗎？我需要和他談談。”他轉身離開。

顯然，產品經理對我們的用戶故事進度不滿意，并且所有開發人員和測試人員現在都感到壓力很大。

 在當天晚些時候的計劃會議中，團隊考慮了所有可能的路徑：幸福的道路、不愉快的道路以及邊緣和邊緣情況。之后，我坐在小隔間中測試用戶故事，盡管大多數任務仍在進行中，但我還是決定進行一些負面測試。在好奇心的驅使下，我開始導航到與數據庫更改無關的區域，并且發現了嚴重的缺陷。

 此時，項目負責人從產品經理的辦公室回來，他看上去并不高興。我轉到項目負責人并通知他，在執行負面測試時，我在登錄頁面中發現了一個嚴重錯誤。

“你正在測試用戶故事以外的東西嗎？”他回答。“請不要嘗試使用有趣的負面內容來破壞應用程序。我們正在趕時間，我認為普通用戶不會遇到該缺陷。”

“好吧，”我說，“我將提交錯誤并繼續執行之前的進度。”

不過，我私下里想知道：“普通用戶”是誰或什么？

測試真實世界

仍然存在軟件質量工程師破壞產品的誤解。測試人員自己會驚呼：“看嗎？我破解了該軟件——當您單擊此處時，它就崩潰了！”

當然，他們并沒有真正做到這一點。軟件不會損壞；它只是按照它的設計和編碼來做，不管是好是壞。

 說到設計，另一個普遍的神話是，所有錯誤都是編碼錯誤和編程錯誤，而實際上，大多數錯誤是在需求和設計期間引入的。軟件質量工程師對系統進行調查，查看系統的功能，然后發現并報告軟件損壞的位置和方式，并確定系統何時在負載或壓力下出現故障，或者像任何用戶一樣在周圍閑逛。

因此，測試人員有義務超越積極的幸福之路，并揭露不太幸福的事物。

 積極的測試是在正確的時間單擊正確的位置。用戶不太可能只會這樣做。用戶在需要時單擊所需的內容。我們無法使用戶一直以相同的方式做相同的事情，因此我們不能依靠我們的自動化測試來涵蓋人機交互。

這就是為什么我不喜歡負面測試一詞的原因——它不是負面的！

我更喜歡“真實世界的測試”。每個用戶都以獨特的方式使用產品，我們不能將用戶彼此進行比較，也不能期望他們使用相同的路徑瀏覽應用程序。用戶不會走幸福的路。用戶不遵循說明，或者說實話，通常甚至都不閱讀文檔。用戶習慣挑戰產品。

 因此，作為測試人員，對我們挑戰產品也至關重要。我們必須改變測試方法，以找出產品的響應方式。出色的測試不僅限于表明產品可以產生預期的結果；這意味著在用戶做某人沒有預料到的事情時了解產品的功能。

 作為軟件質量工程師，我們的職責是像真實用戶一樣行動和思考。我們需要在測試計劃之外進行測試并關閉腳本。開發人員和利益相關者可能會稱其為負面測試，但結果卻是更好的產品，而且都是積極的。

改變對話

 任何軟件都有潛在的風險，無法按預期運行，因此至關重要的一點是，至少要驗證有人登錄時該軟件不會崩潰。當我在登錄頁面中發現錯誤時，我沒有進行負面測試；我正在研究軟件。

因此，我應該以積極的方式進行交流。我們的言語對他人如何看待和理解我們的工作有很大影響。

當我告訴項目負責人我在進行負面測試時發現了一個錯誤時，他的反應令人無法接受是可以理解的。如果我反而說：“當我測試登錄頁面時，我發現了一個嚴重的錯誤”他的反應可能是：“去存檔該錯誤，稍后我們將對其進行研究。”

因此，我認為我們應該停止使用正面或負面的術語。相反，我們來談談“發現”和“調查”。它不那么混亂、更明確，并且避免了開發人員和管理人員說諸如“哦，您只是消極”之類的令人畏懼的潛在問題。

 轉移詞匯幫助我改善了與利益相關者和開發人員之間的溝通。我可以看到方程式的另一個角度，并且我能夠與開發人員進行交流，而不會遇到任何磨擦。現在，團隊將我的工作視為積極改進產品，而不是消極地嘗試破壞軟件。

嘗試將詞匯表從“積極”和“否定”改為解釋性更好的動詞來解釋您的探索。團隊將更容易接受對話，他們甚至可能更珍視您的工作。