應(yīng)用程序或網(wǎng)站的功能測(cè)試是SDLC（軟件開發(fā)生命周期）的最重要階段之一。開發(fā)人員、測(cè)試人員、項(xiàng)目經(jīng)理、運(yùn)營(yíng)人員，甚至管理人員都需要多多少少參與到整個(gè)項(xiàng)目的功能測(cè)試。測(cè)試工作由測(cè)試部門分配，測(cè)試部門提供服務(wù)的穩(wěn)定性至關(guān)重要。在建立多部分協(xié)作的工作文化的過程中，作為測(cè)試人員應(yīng)當(dāng)首先意識(shí)到，不僅可以對(duì)產(chǎn)品進(jìn)行功能測(cè)試，還可以為公司的產(chǎn)品做出更多貢獻(xiàn)。
在應(yīng)用程序交付給用戶面前之前，找出BUG并修復(fù)它們至關(guān)重要。軟件的成功取決于用戶的滿意度，如果應(yīng)用程序的界面中充斥著錯(cuò)誤和BUG，不僅難以贏得新用戶還會(huì)流失老用戶。
大多數(shù)測(cè)試工程師對(duì)功能測(cè)試如何給企業(yè)創(chuàng)造價(jià)值都比較清楚也都很進(jìn)行了很多的嘗試和實(shí)踐。通常，功能測(cè)試會(huì)占用測(cè)試人員一天工作當(dāng)中的大部分時(shí)間。但是，除了執(zhí)行功能測(cè)試之外，還有其他方法可以為產(chǎn)品增加更多的價(jià)值。
作為測(cè)試人員，可以通過應(yīng)用程序的嚴(yán)格CI/CD管道幫助軟件團(tuán)隊(duì)在保障軟件質(zhì)量的前提下更快地迭代。除了功能測(cè)試之外，測(cè)試人員還可以通過以下方法為網(wǎng)絡(luò)產(chǎn)品增加價(jià)值。下面讓我們一一道來。
利益相關(guān)者
每個(gè)項(xiàng)目的不同部分的成員對(duì)項(xiàng)目都有自己不同的需求和想法。但是當(dāng)使用者是最終使用該產(chǎn)品的用戶時(shí)，最重要的還是利益相關(guān)者的的看法嗎？從利益相關(guān)者的立場(chǎng)上消除個(gè)人偏見和思維慣式可以極大地改善測(cè)試過程并增強(qiáng)應(yīng)用程序或網(wǎng)站的健壯性。列出對(duì)交付內(nèi)容表示興趣的人，記錄利益相關(guān)者的期望，并根據(jù)利益相關(guān)者的心態(tài)做出適當(dāng)變化和指定相關(guān)的規(guī)范防止方向跑偏，以避免陷入下圖所示的情況：
因此，除了提供功能測(cè)試以外，測(cè)試工程師還需要根據(jù)與利益相關(guān)者進(jìn)行有效溝通并掌握情況以便及時(shí)了解進(jìn)度。測(cè)試人員遇到BUG時(shí)，通常會(huì)報(bào)告該BUG并追蹤BUG解決進(jìn)度流程。但是，要增加價(jià)值，還需要報(bào)告的內(nèi)容為對(duì)利益相關(guān)者影響方面。另外，還需要檢查準(zhǔn)備好的測(cè)試報(bào)告如何更多考慮全局情況，而不是專注于單個(gè)功能，讓決策者更全面了解軟件的前世今生，以便做出更合適的決策。
解決此問題的一個(gè)好方法是適應(yīng)左移測(cè)試。左移測(cè)試是指即使在產(chǎn)品準(zhǔn)備之前也要盡量進(jìn)行測(cè)試。可以與利益相關(guān)者坐在一起，了解他們真實(shí)的需求和潛藏在這些需求之下的心理動(dòng)機(jī)和期望，以便編寫更加符合業(yè)務(wù)需求的測(cè)試用例避免漏測(cè)和過度測(cè)試。
過渡到QAOps
QAOps是指通過與DevOps團(tuán)隊(duì)進(jìn)行良好協(xié)調(diào)來維護(hù)產(chǎn)品的軟件質(zhì)量。目標(biāo)是提供具有更快的CI/CD流程的健壯的應(yīng)用程序和軟件服務(wù)。QAOps致力于與開發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)與QA部門合作，以并行方式執(zhí)行可擴(kuò)展的測(cè)試自動(dòng)化用例，以便更好地在DevOps中實(shí)現(xiàn)連續(xù)測(cè)試更好更快的進(jìn)行軟件的更新迭代。
傾聽用戶反饋
我們都知道，無論整個(gè)團(tuán)隊(duì)對(duì)產(chǎn)品的感覺如何良好，用戶的意見都是最重要的。了解用戶對(duì)產(chǎn)品的反饋以及功能的實(shí)用性、易用性甚至比功能實(shí)現(xiàn)更重要。在部分場(chǎng)景下，特定功能完全符合需求方和測(cè)試人員的期望，但會(huì)給用戶帶來額外的負(fù)擔(dān)以及使用困難。
測(cè)試人員應(yīng)報(bào)告可能困擾用戶的風(fēng)險(xiǎn)。除了客戶支持團(tuán)隊(duì)之外，還有誰(shuí)能更好地了解用戶的想法？畢竟，他們是直接與用戶密切聯(lián)系的人。將客戶的反饋聲音用作最有價(jià)值的數(shù)據(jù)，并在軟件團(tuán)隊(duì)發(fā)揮巨大的作用。
了解用戶故事
在敏捷開發(fā)框架中，測(cè)試人員應(yīng)該多去了解用戶故事，以評(píng)估發(fā)布周期所需必要的工作。它是從最終用戶的角度對(duì)應(yīng)用程序上的功能的描述。它描述了用戶的分類和屬性，他們的需求和想要的東西以及為什么他們想要特定功能。用戶故事的主要目的是確定項(xiàng)目為用戶帶來的價(jià)值。產(chǎn)品負(fù)責(zé)人和測(cè)試人員了解用戶情況并根據(jù)要求確定任務(wù)的優(yōu)先級(jí)。
了解用戶故事有助于制定驗(yàn)收標(biāo)準(zhǔn)并涵蓋更多使用場(chǎng)景的測(cè)試方案。如果故事內(nèi)容過于龐大，則必須將其分解為不同的模塊，甚至根據(jù)不同用戶分類分解。使用測(cè)試透視圖來評(píng)估用戶故事可以使清楚地了解每一個(gè)節(jié)點(diǎn)花費(fèi)的時(shí)間。市場(chǎng)上有許多在線協(xié)作工具可幫助管理者將整個(gè)團(tuán)隊(duì)保持在一個(gè)儀表板上，可以在其中分配任務(wù)并跟進(jìn)團(tuán)隊(duì)的進(jìn)度。
探索新測(cè)試工具
很多跡象表明傳統(tǒng)手動(dòng)功能測(cè)試人員受到行業(yè)中使用頻率較高的自動(dòng)化測(cè)試工具的威脅。有些人試圖抵制這種變化，覺得自己的某個(gè)技能或者某個(gè)方面的優(yōu)勢(shì)可以抵消這些技術(shù)帶來的不確定性和威脅。不幸的是，一旦我們了解如何利用工具提高測(cè)試效率，大多數(shù)人都會(huì)意識(shí)到自動(dòng)化是一個(gè)福音。作為一名測(cè)試人員，至少應(yīng)具有有關(guān)測(cè)試自動(dòng)化工具以及在領(lǐng)域的相關(guān)機(jī)會(huì)的基本知識(shí)。
使用自動(dòng)化測(cè)試工具，測(cè)試人員可以保留用戶操作記錄的備份，并在適當(dāng)?shù)臅r(shí)間使用日志。其他一些用途包括檢測(cè)日志中的不同模式、模擬用戶行為、復(fù)制生產(chǎn)數(shù)據(jù)等。作為測(cè)試團(tuán)隊(duì)中的探索者，可能需要向他人展示如何輕松使用工具來解決問題的案例。
例如，如果我們考慮進(jìn)行手動(dòng)跨瀏覽器測(cè)試以驗(yàn)證網(wǎng)站的兼容性時(shí)，都知道這樣的測(cè)試非常耗時(shí)且費(fèi)力。如果不了解自動(dòng)化測(cè)試或者對(duì)編程語(yǔ)言使用有困難，幾乎沒人愿意使用Selenium來提高工作效率。作為一名手動(dòng)測(cè)試人員，一開始了解測(cè)試自動(dòng)化時(shí)，可能會(huì)對(duì)Selenium自動(dòng)化測(cè)試感到猶豫和不安全，但是一旦掌握了這些技巧，就會(huì)發(fā)現(xiàn)測(cè)試周期交付速度的提高會(huì)大幅提高。
代碼審查
不要將所有時(shí)間都花在功能測(cè)試上。測(cè)試人員需要對(duì)代碼更改保持更高的警惕，代碼審查提供了一個(gè)很好的契機(jī)。在每個(gè)發(fā)布周期中，都需要有一段時(shí)間開發(fā)團(tuán)隊(duì)可以坐在那里審查滿足發(fā)布要求所需的代碼更改。要進(jìn)行更深入的質(zhì)量檢查，測(cè)試工程師需要積極參與代碼審查過程，并了解應(yīng)用程序中可能發(fā)生的更改。測(cè)試人員不僅應(yīng)該參與其中，而且還應(yīng)該就這些更改做出自己的貢獻(xiàn)。
作為功能測(cè)試員，每天都在與應(yīng)用程序進(jìn)行交互驗(yàn)證。每天都需要執(zhí)行多個(gè)測(cè)試場(chǎng)景，記錄問題，回歸缺陷。雖然代碼審查可能對(duì)你比較困難，但是從實(shí)際使用角度也可以提出一些有價(jià)值的建議。
用戶體驗(yàn)
忽略用戶體驗(yàn)，是在急于發(fā)布應(yīng)用程序的軟件公司中遇到的通病之一。急于發(fā)布功能組件或產(chǎn)品有時(shí)會(huì)優(yōu)先于功能部件或產(chǎn)品的正確性、穩(wěn)定性。在發(fā)布產(chǎn)品之前，必須進(jìn)行深入的檢查，條件允許的話可以通過Beta測(cè)試解決這些錯(cuò)誤。采取必要的手段來收集信息，業(yè)務(wù)指標(biāo)和廣泛的意見，以從用戶的角度評(píng)估產(chǎn)品的質(zhì)量。記錄證據(jù)留存（防止背鍋），并提出建議以促進(jìn)改進(jìn)。
如果是超快速發(fā)版，很可能會(huì)開始出現(xiàn)不一致的死循環(huán)。一般經(jīng)驗(yàn)來講，多個(gè)開發(fā)人員的參與以及將開發(fā)任務(wù)的一部分外包給不同的團(tuán)隊(duì)會(huì)導(dǎo)致更多的不穩(wěn)定風(fēng)險(xiǎn)。用戶接觸點(diǎn)、圖標(biāo)、操作、文本、功能、性能和關(guān)鍵流程是質(zhì)量檢查的一些重要元素。
嚴(yán)守Deadlines
很多測(cè)試人員比較苦惱的就是執(zhí)行了許多重復(fù)的工作以及大量浪費(fèi)在溝通上的時(shí)間，以至于整個(gè)流程會(huì)因此變得混亂導(dǎo)致拖延，有些測(cè)試人員戲稱搬磚。但是事實(shí)上，任何項(xiàng)目規(guī)劃最終的就是時(shí)間節(jié)點(diǎn)，必須嚴(yán)格遵守最后期限。最終目標(biāo)必須是通過避免這些問題來節(jié)省時(shí)間。同時(shí)保持工作進(jìn)展速度和工作質(zhì)量，聽起來像是一個(gè)大坑。但是如果將團(tuán)隊(duì)內(nèi)部和跨部門溝通做好，這兩者會(huì)在一定程度上達(dá)到統(tǒng)一，將會(huì)減少很多不必要的更改，給測(cè)試工作減少很多時(shí)間的浪費(fèi)。
編寫有效的測(cè)試用例和詳細(xì)的測(cè)試報(bào)告是快速執(zhí)行任務(wù)的另一種方法。這一句話中使用了詳細(xì)和快速兩個(gè)詞，聽起來可能是矛盾的，但是詳細(xì)的報(bào)告需要一次性的努力。使用合適的工具和保持良好的使用習(xí)慣，你可以快速訪問查看必要的日志內(nèi)容、用戶數(shù)據(jù)以及錯(cuò)誤信息。
解決BUG
很多測(cè)試人員認(rèn)為他們的工作有時(shí)候十分枯燥，看起來毫無意義，如果沒有發(fā)現(xiàn)BUG，又會(huì)讓他們覺得無法安心上線。一段時(shí)間后，像工具人一樣運(yùn)行測(cè)試腳本可能會(huì)變得有些乏味。執(zhí)行一個(gè)測(cè)試用例，編寫一個(gè)測(cè)試報(bào)告，將該BUG標(biāo)記給開發(fā)人員，并驗(yàn)證該修復(fù)程序聽起來很簡(jiǎn)單，在某種程度上的確是這樣。
但是，如果你想提高自己在這個(gè)工作鏈條中的價(jià)值和地位，那么就不能僅僅把自己當(dāng)做是一個(gè)提示BUG的人，該怎么辦？那就成為一個(gè)解決BUG的人。
最常見的誤解之一：測(cè)試人員就是在發(fā)現(xiàn)、報(bào)告、驗(yàn)證BUG之間循環(huán)。事實(shí)上測(cè)試人員的工作并不會(huì)因?yàn)閳?bào)告BUG而結(jié)束。如果測(cè)試人員通過縮小搜索范圍來找到避免大海撈針地找原因，那就離解決BUG還近了一步。例如，除了指出BUG外，測(cè)試工程師還可以為開發(fā)人員提供一種更輕松的修復(fù)方法。這樣，測(cè)試人員就可以與開發(fā)人員合作并幫助團(tuán)隊(duì)節(jié)省時(shí)間、提高質(zhì)量和效率。縱觀全局，能夠解決BUG的測(cè)試人員可以成為行業(yè)的稀缺物種！在求職市場(chǎng)上也會(huì)更加受到青睞。
學(xué)習(xí)數(shù)據(jù)科學(xué)
擁有大量原始數(shù)據(jù)，重要的是選擇最相關(guān)的信息并熟練地使用它。在這里，我們談?wù)摰氖菙?shù)據(jù)科學(xué)（俗稱大數(shù)據(jù)），它正在挖掘存·儲(chǔ)在數(shù)據(jù)倉(cāng)庫(kù)中的海量信息池。即使逐步交付和部署，也無法測(cè)試所有內(nèi)容，即使是在最佳測(cè)試環(huán)境中也難以測(cè)試！
就生產(chǎn)用途而言，借助大數(shù)據(jù)相關(guān)技術(shù)，測(cè)試人員可以獲得詳細(xì)的信息。但是作為測(cè)試人員，需要學(xué)習(xí)如何充分利用所有數(shù)據(jù)。數(shù)據(jù)科學(xué)可以幫助測(cè)試人員集中精力進(jìn)行更有效的測(cè)試。反過來，這將有助于整個(gè)組織提供更好的交付質(zhì)量。
積極競(jìng)爭(zhēng)
在當(dāng)今快節(jié)奏的技術(shù)世界中，企業(yè)只需一晃神的功夫，就足夠使競(jìng)爭(zhēng)對(duì)手脫穎而出。隨著互聯(lián)網(wǎng)行業(yè)的發(fā)展，以及行業(yè)的內(nèi)卷化的增強(qiáng)，企業(yè)之間的競(jìng)爭(zhēng)將越來越激烈。導(dǎo)致公司產(chǎn)品出現(xiàn)地獄般漏洞的原因，最常見鍋還是測(cè)試人員來背的。
在敏捷大行其道的軟件行業(yè)，測(cè)試人員還需要篩選測(cè)試業(yè)務(wù)情況和其他風(fēng)險(xiǎn)，以將競(jìng)爭(zhēng)對(duì)手產(chǎn)品與自己產(chǎn)品的優(yōu)缺點(diǎn)進(jìn)行比較。除了功能測(cè)試之外，還要考慮其他一些標(biāo)準(zhǔn)，包括可用性測(cè)試、安全性測(cè)試、性能測(cè)試和穩(wěn)定性測(cè)試。
總結(jié)
雖然功能測(cè)試確實(shí)具有不可替代的重要性，但這并不意味著測(cè)試人員可以長(zhǎng)期專注于此！大多數(shù)測(cè)試人員擔(dān)心未知的變化，缺乏編碼技能。真實(shí)情況是除了功能測(cè)試之外，還有其他方法可以為組織增加自身價(jià)值。
測(cè)試是確保產(chǎn)品在到達(dá)最終用戶之前無可替代的環(huán)節(jié)。在某些組織中，測(cè)試人員的貢獻(xiàn)經(jīng)常被忽略。許多測(cè)試人員想知道他們何時(shí)可以與DevOps成員（即使團(tuán)隊(duì)宣城他們就是DevOps成員）一起坐在會(huì)議室上討論產(chǎn)品和技術(shù)方案。QAOps將專注于DevOps中的連續(xù)測(cè)試，從而將盡可能改變這一現(xiàn)狀。
因此，作為一名測(cè)試人員，想知道自己對(duì)服務(wù)或應(yīng)用程序所做的貢獻(xiàn)，可以自己先審視一下自己為產(chǎn)品增加的價(jià)值。即使決策權(quán)屬于領(lǐng)導(dǎo)和項(xiàng)目經(jīng)理，測(cè)試人員在其中的作用也不能忽視。測(cè)試人員可以為其他成員做出正確的決定奠定了基礎(chǔ)，從而幫助團(tuán)隊(duì)充分發(fā)揮全部潛力。
