從負(fù)面測試中排除負(fù)面因素

---

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

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

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

我們到底在測試什么？

早上8點(diǎn)30分，我們的產(chǎn)品經(jīng)理走進(jìn)我們的辦公室，問：“項目負(fù)責(zé)人在哪里？”

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

“將數(shù)據(jù)庫從MySQL遷移到MariaDB的用戶故事的狀態(tài)如何？”

首席開發(fā)人員回答：“我們之所以延后，是因為MySQL主表的某些關(guān)鍵元素不容易遷移到MariaDB?！?

產(chǎn)品經(jīng)理的語氣立即變得更加清晰。“延后多少？幾天，幾周？”

我們的主要開發(fā)人員如實(shí)回答：“至少還有四天?！?

房間里寂靜無聲。最后，產(chǎn)品經(jīng)理說：“你能告訴項目負(fù)責(zé)人來我辦公室嗎？我需要和他談?wù)劇?/span>”他轉(zhuǎn)身離開。

顯然，產(chǎn)品經(jīng)理對我們的用戶故事進(jìn)度不滿意，并且所有開發(fā)人員和測試人員現(xiàn)在都感到壓力很大。

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

此時，項目負(fù)責(zé)人從產(chǎn)品經(jīng)理的辦公室回來，他看上去并不高興。我轉(zhuǎn)到項目負(fù)責(zé)人并通知他，在執(zhí)行負(fù)面測試時，我在登錄頁面中發(fā)現(xiàn)了一個嚴(yán)重錯誤。

“你正在測試用戶故事以外的東西嗎？”他回答?！罢埐灰獓L試使用有趣的負(fù)面內(nèi)容來破壞應(yīng)用程序。我們正在趕時間，我認(rèn)為普通用戶不會遇到該缺陷。”

“好吧，”我說，“我將提交錯誤并繼續(xù)執(zhí)行之前的進(jìn)度。”

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

測試真實(shí)世界

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

當(dāng)然，他們并沒有真正做到這一點(diǎn)。軟件不會損壞；它只是按照它的設(shè)計和編碼來做，不管是好是壞。

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

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

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

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

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

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

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

改變對話

任何軟件都有潛在的風(fēng)險，無法按預(yù)期運(yùn)行，因此至關(guān)重要的一點(diǎn)是，至少要驗證有人登錄時該軟件不會崩潰。當(dāng)我在登錄頁面中發(fā)現(xiàn)錯誤時，我沒有進(jìn)行負(fù)面測試；我正在研究軟件。

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

當(dāng)我告訴項目負(fù)責(zé)人我在進(jìn)行負(fù)面測試時發(fā)現(xiàn)了一個錯誤時，他的反應(yīng)令人無法接受是可以理解的。如果我反而說：“當(dāng)我測試登錄頁面時，我發(fā)現(xiàn)了一個嚴(yán)重的錯誤”他的反應(yīng)可能是：“去存檔該錯誤，稍后我們將對其進(jìn)行研究?！?

因此，我認(rèn)為我們應(yīng)該停止使用正面或負(fù)面的術(shù)語。相反，我們來談?wù)?/span>“發(fā)現(xiàn)”和“調(diào)查”。它不那么混亂、更明確，并且避免了開發(fā)人員和管理人員說諸如“哦，您只是消極”之類的令人畏懼的潛在問題。

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

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