測試團隊的真實故事從負面測試中排除負面因素

測試團隊的真實故事：從負面測試中排除負面因素

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

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

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

我們到底在測試什麼？

早上8點30分，我們的產品經理走進我們的辦公室，問：「專案負責人在**？」

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

「將資料庫從mysql遷移到mariadb的使用者故事的狀態如何？」

首席開發人員回答：「我們之所以延後，是因為mysql主表的某些關鍵元素不容易遷移到mariadb

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

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

房間裡寂靜無聲。最後，產品經理說：「你能告訴專案負責人來我辦公室嗎？我需要和他談談。」他轉身離開。

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

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

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

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

「好吧，」我說，「我將提交錯誤並繼續執行之前的進度。」

不過，我私下裡想知道：「普通使用者」是誰或什麼？

測試真實世界

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

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

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

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

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

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

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

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

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

改變對話

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

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

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

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

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

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

測試團隊的真實故事 從負面測試中排除負面因素