沒有足夠的時間來測試
除了某些專門的或者任務十分重要的應用程序外，很少的軟件項目在開發(fā)周期里擁有充足的時間完成高水平的質量度量。通常情況是，軟件工程里本來就很短的“測試周期”總是不可避免地會被耽擱。即使是最好的項目也很有可能在測試工作上面臨時間限制。在測試管理中這種障礙的影響是不斷變換優(yōu)先級，不斷轉換工作以及為測試結果和質量檢測方法簡化數(shù)據(jù)。
沒有足夠的資源來測試
除了缺少時間外，通常在取得執(zhí)行必要的測試所需的合適資源方面也面臨困難。資源可能被其他工作或項目分享。雖然測試的硬件資源會帶來延遲和困難，但是人力資源的缺乏可能更加難以解決。在測試管理中這種障礙的影響和時間缺乏造成的影響大致相同。
測試團隊并不是總在一個地方
這段時期更經(jīng)常的情況是測試資源可能可以獲得，但是它們不在同一個地方。在各地區(qū)協(xié)調(diào)人力以降低成本已成為家常便飯，但是這造成相當多的技術障礙。在另一區(qū)域的團隊如何共享工件并保持協(xié)同合作，并不會造成延遲和影響整個團隊的和諧?一個項目如何能將區(qū)域分布式開發(fā)的效率發(fā)揮到極至呢?
需求方面的難題
雖然有許多的測試策略，但是確認需求是需要完成的最主要的、優(yōu)先級最高的測試工作。做到這一點需要完整的、明確的和可測試的需求。不夠完美的需求管理會導致測試工作中更大的問題。使用像 RequisitePro 這樣的工具可以幫助極大地提高需求管理并促進有效需求的開發(fā)。
對于有效的測試管理來說，必須有對于最新系統(tǒng)變更和業(yè)務需求的無縫接口。這種接口必須不只是針對需求的描述，也要針對優(yōu)先級、狀態(tài)和其他屬性。此外，這需要開發(fā)需求說明的團隊和執(zhí)行測試的團隊之間最大限度的協(xié)調(diào)分工和溝通。這種溝通必須在確保質量的所有方面進行。
與開發(fā)保持同步
軟件質量所需的另一種團隊協(xié)作存在與測試人員與開發(fā)人員之間的。除了關鍵缺陷之外，軟件開發(fā)中總有一個慣例，那就是測試團隊的工作只有測試人員關注。盡管如此，對于每一個人，特別是對開發(fā)人員來說了解當前的質量水平以及哪些已經(jīng)被測試、哪些還沒有被測試是十分重要的。
為了有效地使用他們的寶貴時間，測試團隊必須跟上不斷變化的代碼、工作版本和環(huán)境。測試管理必須精確識別要測試的工作版本和測試的合適的環(huán)境。測試錯誤的工作版本(或功能)會導致時間的浪費，并嚴重地影響項目進度。測試人員必須也了解什么缺陷是已知的，不需要重新測試的以及哪些是需要確定的。而后測試人員必須將已發(fā)現(xiàn)的缺陷以及促進解決方案的充分信息提供給開發(fā)人員。
什么是質量度量?
測試團隊的一個主要目標是評估并決定質量，但是如何準確地度量質量呢?有許多的方法可以實現(xiàn)，而且根據(jù)系統(tǒng)或應用軟件的類型和開發(fā)項目的特殊性分為很多不同的種類。為了避免曲解，任何一個質量度量方法都是需要清晰明確的。更重要的是，測試方法必須可以獲取和保存，否則它們可能不值得花費成本或者可能是不完整或者不準確的。
報告正確信息
如果能夠為項目傳達測試狀態(tài)和一些質量評定標準，測試工作只是有用的。得出報告十分簡單，但是提供恰當?shù)男畔?在合適的時間，為合適的人)是更加由意義的，主要有以下的原因：
如果只有非常少的信息，那么除了對測試團隊來說減少了感知缺陷的價值外，項目涉眾將不能充分了解影響質量的問題。
如果有過多的信息，那么主要信息的意義和影響就變得模糊。
在如何將信息與不同地方的不同角色分享上總是有技術障礙。
報告結果的另一個需要考慮的事項是如何安排信息以及以采用什么形式(也就是說，信息是基于工具的、基于瀏覽器的還是基于文件的形式)。如果有技術上或者其他限制報告的安排或形式上的約束，項目涉眾對于測試
和質量信息的了解將被減少。數(shù)據(jù)應該以一種清晰有邏輯的設計方式呈現(xiàn)出來，表示適當?shù)囊饬x，而不是以受局限的工具或技術的方式。因此對于項目管理來說在提供寬泛的報告格式方面考慮適應性和接受力的需要是十分重要的。