軟件測試時候發現根本沒有需求，一問開發和需求，發現原來是我們的項目經理口口相傳，告訴開發要怎么怎么做。

　　可想而之，這個過程是沒有設計的，開發過程當中遇到問題，就會問，項目經理即時馬上給出答復。

　　而到了測試，測試人員在完全不了解狀況的時候，在界面上點了點，也不知道要點多少東西，反正一會告訴我說版本測試完了。我心里沒底，想著版本上提到改了這么多東西，怎么馬上就測試完了呢？

　　于是我抱著懷疑的態度去做測試，結果一看發現我們的系統已經大變樣了。以前一個流程的三種狀態變成了現在的未知種數。我傻眼了，這樣怎么可能做測試呢？沒有需求，無法預估到測試場景。怎樣才是測試完成了？更可恨地是部門經理說測試完了沒問題就上線，我的問題是怎樣是測試完了，怎樣是沒問題呢？

　　我告訴部門經理，我無法決定是否上線，因為我不知道如何設計測試場景了，而通過我的測試，我發現了一些開發人員也無法回答的問題，于是我把所有我知道范圍之內的可能造成狀態不同的條件全部列出來了，要求項目經理可我填寫，如果是這樣的輸入條件，輸出是怎樣的？經我這么發問，項目經理也無法填寫我的結果，又推給需求去確認。當然事情暫時沒有結論，現在的狀態是版本暫時沒有上線，我的測試我認為是沒有做完的。

　　針對以上的問題，我覺得好險。測試是項目最后的一道關，如果我不能發現這些問題，上線后，客戶發現了，我們如何解釋呢，我們的項目經理會挺身而出幫你說話，說是因為沒有需求嗎？

　　如果出了問題，我對項目經理沒有這樣的信心。但是我越發覺得測試是多么的重要了，每次上線都是對我個人能力的考驗。而這種混亂狀態下，如果我不能夠發問，我這個測試組的地位只會越來越低，成為別人推卸責任的那個背著黑鍋的家伙。

　　這次我也發現自己在進入這個部門兩個月以后的第一次反抗，前期由于不了解項目的情況，所以出這種問題也是無法察覺的。需求和開發沒有文檔，需求分析和設計沒有做好，我的測試也只能定位比較低。但是通過這次的考驗，我自己越來越多的相信，我能夠做好項目的測試管理，我的測試組能夠在項目過程中充當著不可或缺的角色。

　　沒有需求的測試，很危險，但是我絕不是每次都要用這種方法來對付這個問題，我要告訴部門，你們前期的需求分析是否可以做得更全面一點，開發設計可以多考慮一些，不要每次把問題丟給測試，提高項目的間接成本。