測試人員不是在開發人員代碼實現后才開始介入一個項目的，而是在一個項目開始立項后就開始介入，這個已經是個不爭的問題了。那么，測試在項目的早期可以做哪些工作呢？測試前移是個很大的話題，本文只討論一下需求階段測試人員如何介入？以下所討論的測試可以做的具體事情，無論是在V模型下還是在敏捷模式下都適用，只不過在不同的上下文中，這些事情做的程度和方式有所不同。
首先，需求階段如何定義？比較完整的需求階段至少包括兩個部分：一是初始包需求（OR－Offered Requirement）確定階段，這個階段的參與人員會直接和市場、用服、客戶溝通交流、調研，確定產品開發的初始需求；二是初始需求交給研發團隊，系統工程師進一步分析，結合產品原有基礎、收集內外部需求，得出產品要實現的包需求，并采用系統分析的工程方法開展對包需求的深入分析，得出更細化的需求描述，輸出可以被實現的設計需求，交給軟件實現人員。如果按照CMM流程，前面一個階段CMM貌似涉及 不多，對應Charter之前的工作；后面一個階段對應TR2之前的工作。
一般而言測試的前期介入大多指介入后面一個階段，其實前面一個階段測試也應該參與，當然，參與前面一個更早的需求分析階段，對測試人員的要求會更高一些，需要對系統層面有較好的把握。
（1）測試參與早期需求分析
這個階段收集到的需求都是比較粗的，測試更多的可以從系統驗證的角度考慮問題，即這些粗的需求如果實現后，后期交給客戶時，是否可驗收，有哪些驗收場景、驗收的思路是什么、具體的商用使用場景、需求驗收是否需要特殊的驗證平臺、有哪些驗收難點等等。可以輸出《需求驗收分析報告》。這樣做的好處，一是測試人員通過早期參與，更清楚需求的來源和目的，有利于后期更好的從用戶的角度開展測試活動；二是可以為后期設計驗收測試用例提供很好的分析依據。
如果您在這個階段的測試介入有很多實踐經驗的話，歡迎回復本文分享！
（2）測試參與TR2之前的需求分析
這個階段的需求仍然比較粗，至少開發人員拿到這些OR直接去實現難度還是很大的。系統工程師會從全系統的層面開展稍微細一些的需求分析，得到具體的設計需求，其主要的思路主要是針對每個OR開展場景分析，測試介入的主要工作就是重點參與場景分析工作，因為開發的SE和測試的TSE分析問題的思路是不同的，可以做到很好的互補，所以理想的方式是SE和TSE一起完成場景分析工作：SE偏向從功能、實現的角度分析，TSE更多的考慮非功能屬性方面，比如可靠性、可測試性等，還會考慮用戶分類、異常場景、組網的不同等，這樣二者合作的結果，使得設計需求更易于實現，也一定程度消弱了需求由于分析不充分導致后期的頻繁變更的問題。在敏捷項目中，測試參與的結果經常以“驗收條件（Acceptance Test Conditions）”的形式體現在需求文檔中，每一條需求都對應其驗收條件。
另外，這個階段測試還應該發揮測試的優勢，提出產品的可測試性需求，以便開發在實現階段就考慮進去。
當然，除了上面提到的以外，測試在早期的任何時候都可以針對開發的各種分析輸出件給予很好的評審檢視，缺陷越早暴露成本越低。測試在需求階段參與的更大的意義在于實施preventive testing，這與簡單的文檔review是不一樣的，preventive testing強調的是測試人員用他的測試知識/領域知識去challenge需求和設計，去提前驗證他的idea，去explore需求，可見，探索性測試的思想完全可以在需求階段應用。
此外，Richard Bender所提的基于需求的測試（ReqBT）也是一套可行的方案，在需求寫作初稿階段，ReqBT人員與需求分析人員并行交錯開展工作，一點點地完成需求的模糊度分析、需求的業務邏輯分析、需求的建模以及測試條件生成等工作。
測試在需求階段還可以做哪些，歡迎各位補充！