項目背景：
我們這個項目周期比較長，我是半途加入的，至今即將2年了，而這之前都已經啟動了快1年了。運行組織結構是開發、測試、需求三權分立，微軟好像也是這樣。需求給出定義，開發做出東西，測試檢查質量。如果發現需求沒有的則提交需求bug促使需求新建或變更原有內容，互相促進�？偟膩碚f運轉還不錯，當然過程中也有很多問題，解決了不少，但總還是有問題的。這里就不多說了，畢竟要說產品發布前的故事嘛 ：）
我們定下了最近的一個日期發布產品（具體日期不便透露），所以大家都比較忙碌、緊張，作為測試部分的一員，我們已經好幾周晚上和周六加班了。下面就這里開始故事。
故事一,突然增加的需求。
大約還有1個月的時候，市場部突然提出此次發布的版本一定要有用戶認證功能，主要是收集用戶信息。似乎時間還夠，但實際上對我們來說是不夠的。首先我們要保證當前每周2個版本功能穩定，其次需求要重新根據要求制定詳細到出錯的每個提示。再有需要與其他部門配合（提供服務器數據庫） 事實上因為拖延，該項需求負責人弄出的需求內容還不如開發與測試提出的疑問多，這就半個月過去了；與其他部門的配合工作也沒有個總協調人來跟進，互相之前都在假設別人的工作做好的前提下進行的；除了在線認證還有離線認證，這部分的接口人和工作流程還沒有確定。等等一系列問題需要解決，作為具體測試，堅決把所有可能出現的問題（包括需求沒有明確的）一一提出來，這時候是沒有測試用例的，你對界面規范、用戶操作的習慣、當前功能的目的等等的理解就是你工作的保證。
最終結果還好，雖然還有一些不如人意的地方（有時候為了向市場或開發的部分妥協，如果堅持可能會付出更大代價），總算這個功能穩定了下來，出現的bug數量大約70多個。
故事二,與其他部門產品的矛盾。
因為公司的其他產品是依賴我們這個產品的，就是說如果我們的賣不掉，其他的跟進產品也無法生存，有時候我們的產品甚至是搭送的。 這次因為我們最新版本做出了一些標準化的東西，另一個部門解析我們文件的產品就需要我們進行保護，即我們的軟件輸出的文件只有他們部門的產品解析，但這樣一來我們的文件就不是那么標準了。另外因為我們這次新增加的一個功能可能繞過另外一個部門的產品，這就會影響他們的銷售。
可能還有一些，這些矛盾可能影響產品的發展策略，影響產品的功能變更，雖然測試可以不用管這些，但是從公司、產品、項目角度來看，值得我們思考的問題。
故事三,沒有得到通知的功能變更。
上周五是計劃確定版本的日子，一段時間以來各個功能都比較穩定。大家思維估計都僵硬了，簡單看過基本功能后，我用了一下別組的功能，非常簡單的一個操作，忽然發現多了個提示信息，與功能對應不上，馬上咨詢別組的負責人，她說不知道，然后找開發、需求，轉了一圈原來是之前要做，但是沒說這時候做，開發把這個做完認為沒什么大問題就把代碼放進來了，結果出問題。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
