項目沒有明確定義的（或任何）需求規(guī)格說明書就開始實施，這很常見，特別是在小公司里面。即使是在大型企業(yè)，在他們認為不需要規(guī)范領域，也可能存在項目缺少需求規(guī)格說明書的情況。在這種情況下如何進行測試是一個常見的問題。
在項目缺少需求規(guī)格說明書的情況，并不存在一個做好測試簡單快捷的方法，因為需求規(guī)格說明書對功能性測試的效力有很大的推動作用。其中關鍵的一點是要注意保持對需求來源進行追蹤，和從這些需求源頭上可衍生出哪些需求。這將大大簡化對需求合法性的驗證。以下是在以往測試成功過的幾種策略：
把用戶手冊當作需求規(guī)格說明書使用，這種方法是有效的和符合要求的。如果用戶手冊提供了足夠的細節(jié)信息并且被信息組織編排得很有條理，使用它和使用需求規(guī)格說明書的效果幾乎是一樣的。關鍵是學會在用戶手冊上系統(tǒng)化地查找需求，確認和追蹤這些需求。另外，經常需要從其它的來源獲取需求信息來對用戶手冊進行補充，因為用戶手冊很少會包含壓力和響應時間方面等精確數目信息。
把設計文檔當作需求規(guī)格說明書使用，大部分的開發(fā)人員至少會在某處的文件上記錄或保存系統(tǒng)的一些相關信息。查找出這些設計文檔后，它可作為需求的一個源頭，特別是對于那些在用戶手冊上無法找到的硬性指標需求。關鍵是要小心選擇可用作需求的信息，要注意避免把設計信息當作需求。銷售文檔同樣也可以這樣用。
與人交談。小項目的一個常見問題是“兩只腿的需求”，這是指長駐客戶公司的應用軟件技術支持人員，他們圍繞描述軟件的用途與客戶反復溝通。通常這些技術支持人員都會寫下一些信息，這些信息可用作需求，但多半時候這些信息用處不大，這需要和他們坐下來談論一下這個系統(tǒng)要實現哪些功能。另外，走出去和開發(fā)人員，系統(tǒng)的實際用戶，甚至購買產品的客戶等交談。在每次會談中，及時作筆記，然后把這些筆記作為進行測試的基礎資料。使用常識。使用常識這個方法應該是所有其它方法都失敗后的最后選擇。雖然使用常識可能會發(fā)現問題，但使用這種方法會引發(fā)所發(fā)現故障的重要性和關聯(lián)性的爭論，甚至這個缺陷實際上是不是缺陷也可能需要論證。
測試準備不足情況下的測試
一個關鍵的考慮因素可能是根本上這個軟件是否可測，如果沒有足夠的時間去為一個全新的產品作測試做準備，唯一可行的辦法是向項目管理人員報告這個軟件達不到測試的條件，讓其決定如何處理這個問題。如何項目管理人員做出的決定是宣布這個產品達不到測試的條件，測試人員需提供詳細的信息以解釋為什么這個軟件達不到測試的條件和需要作哪些改進使它達到測試的條件。