項目測試過程中我們的任務也許僅僅只是找出bug，但是對於bug產生的本身可能並不關心，因爲績效考覈只關心bug的質量和數量，所以使得我們測試人員的眼光變得很狹隘，甚至可以說是膚淺。最近在接手一個項目測試任務時，發現我們的工作是如此的單調，而且不愉快，原因在哪兒呢，大家一致總結是因爲沒有需求，或者說有需求但是不明確，可能是由於習慣性的軟件開發流程將我們套牢了，測試總是變得很被動，而且必須只能從需求入手才能開展測試，但事實證明，需求也有太多的不合理，因爲當需求變得沒有依據時，我們還能指望誰呢？
很久沒有對理論性的東西進行探討了，這次項目測試中讓我深有體會，理論不只是理論，我們應該如何正確理解這些個理論和流程，習慣性被接受，還是不斷地去思考，我想可以更理性一些，畢竟工作不只是爲了工作，而是爲了更好的工作。如何更好的開展工作，就需要我們通過各種辦法來改善我們的工作。測試工作確實很枯燥，可能並是所有的人都這麼認爲，至少我也不這麼認爲，因爲我總是在想辦法讓我的測試工作更簡單，更高效，比如研究自動化，再比較多去了解學習一些測試工具，通過等等這些元素的攝入，我們也會驚歎原來工作可以這樣來完成，因爲這樣更有技術含量，作爲一個技術行業的人員，還有什麼能比技術更吸引你的，除非你確實不是一個安心搞技術的人。再回到項目測試過程中，我們習慣來按照流程來工作，但是在流程不完善的情況下，我們如何開展呢，對於測試工作來講，比較多見的就是沒有需求，因爲開發人員對需求很明白，不過都在他們腦子裏，但最後產品上線了，用戶反饋的卻是這麼功能是幹嘛用的，爲什麼少了這個那的的？質問測試人員？我想我回答不了，我只能說我的需求來源於開發，因爲他們說改就改，說不改就註釋說這個板塊可能不要，或者不重要，用戶不怎麼用，太多理由了，也許大家都很痛苦。但這裏我只想說一點，我們的設計是怎麼來的呢，我們的架構是怎麼來的呢？這些個設計是合理的嗎？記得有一次我問一個項目組的負責人關於項目架構設計，他反問了我一句什麼架構，搞得我好像比開發還專業一樣，然後我還跟人解釋了半天，後來人就給我發來網絡拓撲圖，我也只能接受，因爲追問幾次人家都不耐煩了，這就是我們的項目開發負責人，就連他們都沒有設計階段的產物，還能指望下面的開發人員有設計方案嗎？當然很佩服他們，最後產品也如期能提交上來，痛苦就留給測試人員來斟酌吧，畢竟各負其責，因爲產品不合格，測試也是要負責任的。當然我們也有接到過一些設計實物，那就是圖片，基本都是PS的，然後隨便貼出在一些文檔上加以說明，這就是所謂的設計方案，甚至可以說代替需求文檔，我想要開始習慣這些了，因爲他們準備繼續這個幹，更可笑的是，開發出來的產品還跟PS的方案圖片不一樣，我簡直不能想象設計可以這樣做。當然這只是描述我們實際工作中經常碰到的一些問題，以次可以想想我們的測試工作是何等被動，又豈能說有成果。
通過幾次這種痛苦的磨練，我開始懷疑我們是否還需要如此被動的開展我們的測試流程，因爲都被開發搞的焦頭爛額了，更是被需求忽悠無法容忍了，不過什麼樣的環境我們還是得接受下去，只有通過自個卑微的努力去一點一點地去改變和完善我們的流程，畢竟產品的質量不是一天就可以抓起來的。而對於測試過程我還是吸取了不少經驗，對於今後的項目管理我也有我個人的一些收穫，這些都是痛苦的教訓。以前我很不理解還有測試架構師這個職位，前段時間看過一篇關於軟件設計師與測試架構師的PK，讓我深有體會，測試架構師是什麼角色，這個角色的重要性，正如我今天所碰到的這些問題，如果一個項目中有這樣的角色，那測試過程將更加完美。測試架構師與軟件設計師的PK就好象測試人員與開發人員的PK，但是從技術含量的角度，軟件設計師和測試架構師可能更容易達成一致，因爲產品在設計階段的問題是至關重要的，一般能成爲測試架構師，我想水平也肯定不是一般的，所以說如何讓測試人員參與軟件設計，並不只是一個形式，在沒有測試架構師指導的情況下，測試人員參與軟件設計是絕對有利於軟件設計的，因爲很多時候軟件設計本身就沒有依據可言，就需要測試人員扮演用戶的角色來對設計進行測試，提出意見之後達成有效的共識。