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