讓測試人員參與軟體設計

項目測試過程中我們的任務也許僅僅隻是找出bug，但是對于bug産生的本身可能并不關心，因為績效考核隻關心bug的品質和數量，是以使得我們測試人員的眼光變得很狹隘，甚至可以說是膚淺。最近在接手一個項目測試任務時，發現我們的工作是如此的單調，而且不愉快，原因在哪兒呢，大家一緻總結是因為沒有需求，或者說有需求但是不明确，可能是由于習慣性的軟體開發流程将我們套牢了，測試總是變得很被動，而且必須隻能從需求入手才能開展測試，但事實證明，需求也有太多的不合理，因為當需求變得沒有依據時，我們還能指望誰呢？

　　很久沒有對理論性的東西進行探讨了，這次項目測試中讓我深有體會，理論不隻是理論，我們應該如何正确了解這些個理論和流程，習慣性被接受，還是不斷地去思考，我想可以更理性一些，畢竟工作不隻是為了工作，而是為了更好的工作。如何更好的開展工作，就需要我們通過各種辦法來改善我們的工作。測試工作确實很枯燥，可能并是所有的人都這麼認為，至少我也不這麼認為，因為我總是在想辦法讓我的測試工作更簡單，更高效，比如研究自動化，再比較多去了解學習一些測試工具，通過等等這些元素的攝入，我們也會驚歎原來工作可以這樣來完成，因為這樣更有技術含量，作為一個技術行業的人員，還有什麼能比技術更吸引你的，除非你确實不是一個安心搞技術的人。再回到項目測試過程中，我們習慣來按照流程來工作，但是在流程不完善的情況下，我們如何開展呢，對于測試工作來講，比較多見的就是沒有需求，因為開發人員對需求很明白，不過都在他們腦子裡，但最後産品上線了，使用者回報的卻是這麼功能是幹嘛用的，為什麼少了這個那的的？質問測試人員？我想我回答不了，我隻能說我的需求來源于開發，因為他們說改就改，說不改就注釋說這個闆塊可能不要，或者不重要，使用者不怎麼用，太多理由了，也許大家都很痛苦。但這裡我隻想說一點，我們的設計是怎麼來的呢，我們的架構是怎麼來的呢？這些個設計是合理的嗎？記得有一次我問一個項目組的負責人關于項目架構設計，他反問了我一句什麼架構，搞得我好像比開發還專業一樣，然後我還跟人解釋了半天，後來人就給我發來網絡拓撲圖，我也隻能接受，因為追問幾次人家都不耐煩了，這就是我們的項目開發負責人，就連他們都沒有設計階段的産物，還能指望下面的開發人員有設計方案嗎？當然很佩服他們，最後産品也如期能送出上來，痛苦就留給測試人員來斟酌吧，畢竟各負其責，因為産品不合格，測試也是要負責任的。當然我們也有接到過一些設計實物，那就是圖檔，基本都是PS的，然後随便貼出在一些文檔上加以說明，這就是所謂的設計方案，甚至可以說代替需求文檔，我想要開始習慣這些了，因為他們準備繼續這個幹，更可笑的是，開發出來的産品還跟PS的方案圖檔不一樣，我簡直不能想象設計可以這樣做。當然這隻是描述我們實際工作中經常碰到的一些問題，以次可以想想我們的測試工作是何等被動，又豈能說有成果。

　　通過幾次這種痛苦的磨練，我開始懷疑我們是否還需要如此被動的開展我們的測試流程，因為都被開發搞的焦頭爛額了，更是被需求忽悠無法容忍了，不過什麼樣的環境我們還是得接受下去，隻有通過自個卑微的努力去一點一點地去改變和完善我們的流程，畢竟産品的品質不是一天就可以抓起來的。而對于測試過程我還是吸取了不少經驗，對于今後的項目管理我也有我個人的一些收獲，這些都是痛苦的教訓。以前我很不了解還有測試架構師這個職位，前段時間看過一篇關于軟體設計師與測試架構師的PK，讓我深有體會，測試架構師是什麼角色，這個角色的重要性，正如我今天所碰到的這些問題，如果一個項目中有這樣的角色，那測試過程将更加完美。測試架構師與軟體設計師的PK就好象測試人員與開發人員的PK，但是從技術含量的角度，軟體設計師和測試架構師可能更容易達成一緻，因為産品在設計階段的問題是至關重要的，一般能成為測試架構師，我想水準也肯定不是一般的，是以說如何讓測試人員參與軟體設計，并不隻是一個形式，在沒有測試架構師指導的情況下，測試人員參與軟體設計是絕對有利于軟體設計的，因為很多時候軟體設計本身就沒有依據可言，就需要測試人員扮演使用者的角色來對設計進行測試，提出意見之後達成有效的共識。

本文轉自一米一陽光部落格園部落格，原文連結： http://www.cnblogs.com/candle806/archive/2011/02/12/1952587.html   ，如需轉載請自行聯系原作者