錯誤的發(fā)生，整個(gè)網(wǎng)絡(luò )的發(fā)展過(guò)程。這是完全正常的。不管如何努力，一個(gè)團隊的嘗試，錯誤蔓延到項目。但這意味著(zhù)，總是有改進(jìn)的余地。

你會(huì )發(fā)現數以百計的名單在談?wù)撳e誤，可以避免在網(wǎng)站開(kāi)發(fā)項目。

然而，大多數這些列表主要解決Web開(kāi)發(fā)過(guò)程的管理和技術(shù)方面的問(wèn)題。他們很少會(huì )覆蓋其他關(guān)鍵部件，如質(zhì)量保證（QA）階段。

在這篇文章中，你會(huì )發(fā)現的bug跟蹤錯誤避免的一些見(jiàn)解。

QA和測試的一個(gè)關(guān)鍵因素

測試和缺陷跟蹤階段或測試階段是在任何Web開(kāi)發(fā)過(guò)程中非常關(guān)鍵的一步。

正是在這個(gè)階段，所制備的原型或新設計的網(wǎng)站進(jìn)行全面的檢查。

你不能完全忽視這個(gè)階段推出一個(gè)網(wǎng)站。

邏輯很簡(jiǎn)單：當開(kāi)發(fā)人員工作在幾個(gè)小時(shí)的項目，他們進(jìn)入“視覺(jué)倦怠模式很可能”。

從反饋團隊回顧有助于揭示原型，完全錯過(guò)了，因為開(kāi)發(fā)人員專(zhuān)注于更大的問(wèn)題。

這個(gè)反饋階段確保網(wǎng)站的每個(gè)組件運行正常。

這一階段還檢查網(wǎng)站的用戶(hù)界面?？捎眯詼y試通常是項目階段的一部分。

軟件需要測試

想象一下，如果一個(gè)汽車(chē)經(jīng)銷(xiāo)商賣(mài)給你一個(gè)未經(jīng)檢驗的車(chē)會(huì )發(fā)生什么。

它會(huì )把你的生活和你所愛(ài)的人的生命危在旦夕。

嗯，未選中的網(wǎng)站受到不太嚴重的后果，但從你的用戶(hù)負反饋可以花費你的收入損失。這就是你想要的最后一件事。

因此，QA階段需要收集反饋從不同的當事人在Web的發(fā)展一樣，項目經(jīng)理，客戶(hù)，同事，和設計師。

收集反饋需要團隊和客戶(hù)之間的密切互動(dòng)。在每一個(gè)近距離的互動(dòng)，總有機會(huì )曲解。

這導致在項目交付中獲得意想不到的延誤，預算上沮喪的客戶(hù)和其他利益相關(guān)者。

這就是為什么我們會(huì )談?wù)?0的bug跟蹤錯誤可以避免。

一：QA？誰(shuí)有時(shí)間呢？！

開(kāi)發(fā)一個(gè)網(wǎng)站是一個(gè)龐大的系統工程，需要大量的工作。由于高強度的工作，很多球隊不給QA過(guò)程需要注意他們可能會(huì )提供一個(gè)錯誤的網(wǎng)站客戶(hù)端。

結果：該項目可能是他們與客戶(hù)的最后一個(gè)項目，他們可以承受的負面宣傳。

坦率地說(shuō)，你不能忽視QA階段。

除非你確定你的產(chǎn)品，你不能把它交給客戶(hù)。你得去問(wèn)別人關(guān)于你的產(chǎn)品的反饋。你要知道，理解并進(jìn)一步與你收到的反饋測試，你的同事，客戶(hù)，和客戶(hù)的客戶(hù)。反饋是非常重要的，這就是為什么你的質(zhì)量保證期是絕對必要的。

二：多信道通信

一旦網(wǎng)站準備，開(kāi)發(fā)團隊將要求反饋當事人。

球隊需要盡可能多的反饋。這意味著(zhù)所有的當事人提出自己的反饋使用自己的通訊方式如電話(huà)、短信、郵件和便簽。

他們甚至為感謝咖啡時(shí)間反饋。

顯然，這種反饋是主觀(guān)的，更重要的是，不一致。許多這樣的反饋不正確記錄。那時(shí)候就無(wú)法為球隊工作的方式通過(guò)這個(gè)散亂的信息。

當你收集反饋信息，對你的要求。

遠離主觀(guān)的和開(kāi)放性的問(wèn)題，如“你怎么看待我的網(wǎng)站嗎？“或”你喜歡的網(wǎng)站嗎？“

在尋求別人的意見(jiàn)，給他們發(fā)一封電子郵件包含所有關(guān)鍵信息的網(wǎng)站，其目標客戶(hù)。

向他們解釋?zhuān)?a target="_blank" class="infotextkey" style="margin: 0px; padding: 0px; outline: none medium; text-decoration: none; color: rgb(46, 44, 44); text-align: center;">網(wǎng)站建設的目的、目標客戶(hù)的資料，對目標客戶(hù)的消費行為，以及如何幫助在網(wǎng)站提供客戶(hù)需求的解決方案。

給人這樣一個(gè)框架后，你將能夠得到準確的反饋。

三：在另一端發(fā)生了什么？

在今天的數字世界中，工作區發(fā)生了變化。企業(yè)不再坐在一個(gè)單一的位置，相反，很多員工遠程工作。

當這樣的一個(gè)廣泛的團隊一起工作的一個(gè)項目，單純依靠通信和協(xié)作的電子郵件或聊天之路不好走了。

一個(gè)團隊只能是效率和生產(chǎn)力，當它的每個(gè)成員在同一頁(yè)。

這就需要一個(gè)透明的反饋流程。

在一個(gè)沒(méi)有實(shí)時(shí)反饋工具這是使用，球隊可能會(huì )遭受誤解，可以花費你大量的時(shí)間和金錢(qián)。

你的團隊應該有一個(gè)合作和溝通的工具，讓每個(gè)團隊成員了解其他人的活動(dòng)。實(shí)時(shí)通信工具，打破團隊成員之間的空間和時(shí)間的障礙。

最好是鼓勵團隊使用的視覺(jué)傳達方式，如截圖的問(wèn)題然后發(fā)送反饋給正確的人。

當你視覺(jué)傳達，另一端的人會(huì )立即無(wú)需通過(guò)閱讀文本理解問(wèn)題噸。

四：number爐：錯誤的假設

“我以為你會(huì )做的bug跟蹤”或者，“我認為這已經(jīng)包括在內?！边@些說(shuō)法聽(tīng)起來(lái)熟悉嗎？

不幸的是，這些短語(yǔ)的一個(gè)項目的質(zhì)量保證期是很常見(jiàn)的。

這表明，團隊成員的工作是不考慮什么對球隊的休息和簡(jiǎn)單的假設。

然而，當一個(gè)客戶(hù)委托你開(kāi)發(fā)一個(gè)網(wǎng)站，不應留下來(lái)的假設。

在言語(yǔ)交際中的任何地方。所有文件這是約定，讓每個(gè)人在回路。期。

五：客戶(hù)反饋，呵呵…誰(shuí)在乎呢？！

你的客戶(hù)問(wèn)你一個(gè)蘋(píng)果，你送桔子。這是當它開(kāi)始花費金錢(qián)。

這只是因為你沒(méi)有問(wèn)客戶(hù)他們在網(wǎng)站發(fā)展的每個(gè)階段反饋。

確保你保持嚴格的和頻繁的你的團隊和你的客戶(hù)之間的溝通水平。

你的團隊是不是他們創(chuàng )造的“感覺(jué)”很好的一個(gè)網(wǎng)站。

他們創(chuàng )造了完全基于客戶(hù)端的指令和需求的產(chǎn)品。

跟你的客戶(hù)，并讓他們了解每一步的發(fā)展。儀表盤(pán)與客戶(hù)分享他們的團隊獲得最新的更新和發(fā)送他們的反饋互動(dòng)。如果可行的話(huà)，還去一個(gè)測試版發(fā)布。選擇您的樣品從客戶(hù)的目標受眾和測試，測試，測試！

六：等待直到完成它

如果你在你的設計和開(kāi)發(fā)階段完成后，開(kāi)始你的測試過(guò)程中，你可能太長(cháng)的等待。

有一個(gè)很好的機會(huì )，你可能會(huì )遇到不愉快的意外在第十一小時(shí)。

你最終會(huì )超出你的預算和期限。

測試和反饋應盡早開(kāi)始。評價(jià)在項目每個(gè)階段的測試。

它可能花費你幾塊錢(qián)，但如果沒(méi)有早期的產(chǎn)品的生命周期，如果事情出錯了，你得花上一晚。

七：不一致的錯誤報告

你的測試團隊已經(jīng)發(fā)現錯誤并報告給開(kāi)發(fā)商。但如果你有一個(gè)不當的或報告這些錯誤的好方法，它會(huì )導致很多不愉快的場(chǎng)景。

錯誤報告將導致任何問(wèn)題或對權利問(wèn)題的固定，但在錯誤的方式。這顯然是你不想要的東西。

你需要一個(gè)一致的和適當的方式報告錯誤。你可以用這樣的工具usersnap管理漏洞和合作反饋。帶注釋的截圖和bug報告，你會(huì )看到你的用戶(hù)和測試者看到了什么。

八：錯誤反饋流程

一個(gè)很好的例子就是網(wǎng)頁(yè)設計。網(wǎng)頁(yè)設計師一般都知道如何創(chuàng )建一個(gè)好的設計和運用這些知識的任何項目。

然而，他們不會(huì )永遠是正確的即使他們可能非常的選擇。

這個(gè)測試團隊有時(shí)犯的錯誤及時(shí)給予建議，在這個(gè)問(wèn)題上無(wú)需等待來(lái)自其他來(lái)源的更多反饋。也許設計需要一個(gè)營(yíng)銷(xiāo)專(zhuān)家的輸入？或者你的客戶(hù)支持團隊需要有人去看一看嗎？

確保每個(gè)元素從權利人獲取反饋。

九：忽略關(guān)鍵領(lǐng)域

即使，雖然都是同步的前端和后端的任何應用程序都是同等重要的，測試團隊通常更側重于功能方面容易忽略的性能測試

因此，開(kāi)發(fā)團隊很小的反饋在Web頁(yè)面的前端性能直到公布。這導致了用戶(hù)界面的問(wèn)題。

每一個(gè)階段，即使子Web項目的開(kāi)發(fā)階段是至關(guān)重要的。測試團隊應該確保他們不忽略任何部分的項目。試著(zhù)在每個(gè)計劃測試階段

十：不重要的錯誤

沒(méi)有什么可以100%個(gè)免費的應用程序?？偸菚?huì )有和任何應用操作設計限制某種。很多測試人員，因此，不報告不重要的錯誤。

有時(shí)，這可能會(huì )導致一個(gè)更大的問(wèn)題，后來(lái)當網(wǎng)站全面啟動(dòng)和運行。

不重要的錯誤應該被記錄；不同的是你給他們的優(yōu)先事項。

一個(gè)有經(jīng)驗的測試人員了解好的做法和錯誤的區別。他們也明白給了相關(guān)優(yōu)先權的重要性。