6、必備特性（Necessary Traits）
軟件測試工程師除了技術，還要求具有否定性的創造力；探測技巧；總體理解產品的能力；用客戶的眼光進行評估；懷疑的而不是敵意的態度；能經受得住壞消息而保持目標；擁抱新技術的熱望等特征。
否定性的創造力。一個軟件工程師不能怕引起一個產品的癱瘓或燒毀。在軟件測試中，邊界意味著被超越而不是被遵從。如果一個程序對某個值的極限為10(例如，可以在一時間被打開的最大文件數)，測試工程師的第一想法應當是“如果我把那個值取11，或0，或10.1，甚至不設這個值會如何？”
在我的早期的工作生涯中，有一次我測試一個開發和QA工程師遺漏下來的PC數據庫。有問題的數據庫是2.01版。這本身就說明產品有問題。2.0版沒解決1.0版的所有缺陷嗎？或者2.0版又加入了新的缺陷？很遺憾因為時間緊我沒有調查這些，只是證實了最后的缺陷修復后就告捷了。
這是很大的錯誤。我應當重測開發人員所謂“沒有變化”的所有產品功能。2.0版本中的缺陷確實復修了，但在修復的過程中，有人破壞了請求。事實就是如此，在數據庫里不能搜索數據了，第一個收到這項產品的beta客戶發現了這個缺陷。
我宣布以前的測試無效，要求對產品進行全面測試。找到幾個缺陷之后，我發現這個數據庫讀取寫保護文件或寫保護了的磁盤的時候就會引起癱瘓。開發人員很吃驚我會試著寫保護一個數據庫。他們的反應就是：“沒人會這么干的！”產品的市場經理很快用他們的方式承認了錯誤。
探測技巧。在一個理想的世界中，軟件測試應當在一個經常更新的寫得很清楚的功能與設計說明文件(一般被稱為specifications”)中被完整而精確地描述。不幸的是，這一完善被開發程序每一方面文件的任務，包括記錄在開發中對程序不可避免的改變，要花很多的時間和精力以至于人們無法完成編程。而且花費也太大。
正式與非正式的信息源 正式系統 要求文件 功能說明書 設計說明書
非正式系統 用戶文件 與其他開發人員的交流 與軟件支持人員的交流
有關產品的文件 有關產品的缺陷 從工作于相關或早期版本產品獲得的“局部知識”
因為我們不是在理想世界里編程，測試工程師應當能夠自己找出工作的方式。典型的是，總會有一些設計和功能說明書讓測試工程師用于開始他的研究。這些文件能看成為描述被測試軟件的“正式”系統。測試工程師應當能用更廣大的“非正式”系統的信息來擴展“正式”系統的信息。同時，在項目周期的任何一個點，任何文件都可能是正確或不正確的，所以測試工程師必須根據對軟件工作模式的觀察，與開發人員和其他項目人員的交談，或對有關或看上去不那么相關文件的審核，來確定文件的精確性。
總體理解產品。在一個程序項目是，軟件開發工程師主要把他們的精力和注意力集于自己的項目部分。結果當這些項目部分組合在一起進行測試的時候，就會碰到兼容性的問題。到產品寄給一個客戶之前，唯一能見到整個產品的就是測試工程師。因此測試工程師必須能夠對整個產品的操作與使用保持一種“系統”的眼光。
測試工程師對產品的任何一部分的操作可能不是最好的專家，但他必須是產品整體操作的專家。例如，如果被測的產品是一個類似于Microsoft Office的由文字處理、擴展頁和其他有關程序組成的辦公室自動組件，測試工程師必須了解每個程序的操作，各個程序之間的相互作用和客戶其他的軟件硬件和軟件環境。
用客戶的眼光進行評。測試工程師必須是客戶的擁護者。被測程序有可能運行可靠滿足所有的設計要求，但在客戶的軟件環境中未必能夠用。產品被送到客戶之前的測試之一就是要證實產品達到了客戶的要求與期望。在這項測試中，測試工程師必須模擬用戶的軟件環境，把自己放到他們的位置上。
關于軟件功能“正確”而不能滿足客戶需要的一個悲劇性的例子就是美國航空公司965航班1995年在哥倫比亞卡利市的一次失事。在飛行著陸時，空中信號控制系統指示機組人員朝一個叫“Rozo”的航空信號燈飛。這個信號燈在航空圖中標為R。機組人員把R輸入到飛行管理計算機中，看到了明顯是由近到遠列出的六個航空信號燈。機組人員選了第一個信號燈，以為這就是Rozo。但那不是。自動駕駛儀把飛機向左轉了九十度，撞到了山上。
什么地方出錯了呢？當航空表里把Rozo列為R的時候，飛行管理計算機要求機組人員輸入信號燈的全名調出它的方位。同時，計算機只顯示了信號燈的編碼字母和方位。計算機功能“正確”，但不滿足用戶的需求。
要求變化。項目剛開始時的要求與最終項目完成時的要求一致的情況是極少見的。有時技術變化了，產品必須改變以適應于技術。有時競爭對手的產品具有你的產品所沒有的功能。很多情況下，客戶的或潛在客戶的要求需要變化。這些因素合在一起的一個例子就是目前Microsoft Internet Explorer和Netscape的競爭。
隨著計算機首次用戶的迅速增加，今天的測試工程師比以往更需要把自己置于客戶的位置上。這些新的非技術用戶不愿意接受缺陷，對缺陷的解釋或理性思考，或通過“升級”修正缺陷。他們只希望他們所買產品的軟件和硬件都是能工作的。
懷疑的而不是敵意的態度。測試工程師不能按表面值接受事物，必須執著地對一切提出疑問直到被證實。工程師必須用一種與項目的其他的人合作精神來平衡這種懷疑性與執著性。測試部門與其有關部門的關系可能會變得緊張，特別是在大量缺陷被發現后，或者在每個找出的缺陷會潛在地延遲產品的發貨時間而延遲了項目時。測試工程師應當記住要攻擊程序的整體性，而不是程序員。
經受得住壞消息而保持目標的能力。一個測試工程師必須忠實地匯報產品中的缺陷。這一信息應當被項目組歡迎，因為每一個測試工程師遇到的問題(除非加入新的問題)都意味著減少客戶會面臨的問題。但不幸的是很多人不想聽到有問題，特別是在程序項目的后期。
測試工程師應當能處理因為工作做得太好而引起責備的情況。這對有些人來說是很難做到的，會嚴重地影響斗志與自尊。
看起來常常是測試工程師阻撓了向客戶交貨�？陀^的項目經理才能感覺到測試工程師是在對項目提供有價值的服務。我清楚地記得一個項目經理舉起他的手求我他要的是：“解決方案，不是問題！”(他不明白解決方案的實現有時要求一個問題的解決)有時項目經理在項目計劃不方便的時候對于因為發現缺陷而打折是有壓力的。在這些情況下，測試工程師應當能基于他對產品的經驗和知識進行辯護，但他不應表現為象是他個人受到了威脅。
如何避免這些情形呢？就測試的內容、時間及如何更新測試結果和缺陷信息，設定其他項目組成員的期望。我曾經為一個希望延遲產品發送日期的QA經理工作過。他的目的不是為了產品成功，而是政治權力的操縱。他確信自己能被提升，把一些為他工作的工程師指定為“manager”，開始自稱為“director”，還要大樓管理人員把他的辦公隔間加寬一英尺。(當然，“director”沒有實現，只是他的座位有了更多伸腳的余地。)
文章來源于領測軟件測試網 http://www.kjueaiud.com/
