沒有需求文檔，沒有功能詳細設計，造成的測試紕漏
一個系統的開發需求，僅僅2-3頁，一頁講的是背景，另外的講的是有幾個模塊。
然後就開始開發，開發憑藉自己的經驗做出界面與功能，測試也同樣憑藉經驗，列出對應的測試用例，根據界面再進行補充。
造成的問題：在有些功能上，是否這樣做，開發不清楚，開發不清楚導致根據開發開發的功能測試用例同樣具備了是否可行的模棱兩可。解決辦法：找產品問清楚是否這麼做，最怕的是產品也不知道是否這樣做。
非常影響用例質量的地方：有些特殊的輸入框或者特殊功能點，因爲沒有對應的詳細文檔，不清楚是否做限定，有些比較通用的，測試用例是能夠覆蓋到的，有些是需要需求文檔或功能設計上提出來的，用例上纔會覆蓋這方面。因爲作爲測試無法決定這個功能點是否這麼做或那麼做，而且你覺得得可能是正確的，但是上面人不同意，到時又說不清了。因此用例一般就是根據需求、設計文檔來的。所以沒有這些文檔，用例很難保證質量。導致測試完了，仍然難以讓人滿意。
這些其實都還好，關鍵看領導層是否意識到，用例的完整性與產出的前提。然後就是當沒有這些前提的時候，工作氛圍很重要，如果是在一個工作氛圍好，經常談論本次要開發功能上的細節，然後敲定的，其實做好對應記錄，然後你細節不清楚的繼續討論，最後能夠得到確定的結果的。這些問題都是能夠解決的。
比較糟糕的是一種情況，對應的需求、設計文檔沒有，完了工作氣氛不夠活躍，各幹各的，基本都不討論軟件本身設計上合理性與是否確認有些功能的確定性。而且有些奇葩要求測試看看這個功能應該怎麼設計或者你認爲應該是什麼樣的就怎麼設計用例（當然如果你話語權高的話，能敲定還好，否則真的白費功夫），這樣就很容易造成後期大量的修改，以及重複的修改。造成的質量後果，懂的都懂。
沒有需求文檔，功能設計文檔，寫好的用例上傳，也不進行評審，然後出了問題就找測試，如果問題是用例上有測試疏忽了，或者是淺顯的問題，測試用例沒有覆蓋，那麼責無旁貸。但是用例都不評審就算了，有些時候，沒有定好的功能調整過的、有的是需要改進的、有的是演示人員不瞭解系統而造成的問題（你演示前不過一遍，演示的時候發現這個功能應該改過了，不知道刷下緩存嗎），他媽的都說是bug，那就是喪盡天良的說法了。最關鍵在這樣的前提下還要求100%覆蓋，腦子真是個好東西。
如果你是一個測試，當沒有需求、功能設計等文檔導致你用例產出無法保證質量的，應該儘早提出來，否則後面你提出來了，大概率會認爲你能力問題，本身就是你此刻的公司就不清楚這樣一個流程，用例產出的根據。然後測試用例設計好了，一定要上傳要求評審，如果你根據用例測試完了，出現了，你纔有不背鍋的可能，但是又時候不管有沒有評審，你根據用例測完了，出了問題還是找你，沒辦法你的處境是你的測試其實不需要依據，系統沒問題，你就沒事，系統有問題，你就算24小時都在找問題，你還是有事。
無論在什麼情況，我們做好問題的記錄是很重要的，把你認爲是錯誤，認爲該改進（看公司是否有着方面要求，可以嘗試，如果公司認爲是多餘的後續可不做）的點記錄下來，拿出來給團隊討論，至於討論與否，看公司了。無論討論與否問題記錄上傳還是要做。至於說覺得不值得留下了，至少該做的我們要做，要走就堅決的。
有些時候積極性是會被團隊同化，好的團隊，好的氣氛，是非常不錯的，加上好的流程，合作溝通起來就比較流程，上班自然就覺得充實開心。