從IT崗位轉到軟件測試差不多有快2年了，每一個行業的人都會在考慮自己所作的工作或者行業是否得到公司的重視，提高所在團隊的地位。下面是從論壇討論時候的帖子現在整理出來給大家都看看。
   
    通常真正要考慮這個問題的是一個公司的測試經理，當然站的多高看得多遠，對于普通測試人員能在這個問題上有深入的考慮，我只能說句敬佩了。
   
    個人的地位很大程度決定于你所在的團隊，而一個測試團隊和其他團隊或其他組織內的團隊并無二異，它的地位取決與它所產生的商業價值，是諸多主客觀因素決定的，而在現今的大環境下客觀因素有時候占主導。各個公司并非沒有牛人，為什么很少有人能真正扭轉現狀。但是我們應當看到的是整個情況正在向積極的一面發展，而對于客觀條件的過分抱怨也沒有多大意義，讓我們來分析一下造成現狀的一些原因。
   
    測試一般不直接產生商業價值，它是通過減少開發的損失來體現價值的。這里說一般是因為有例外，假如你能獨立接測試項目能夠直接創造利潤。但現在有這個能力的公司屈指可數，本土的更是鳳毛麟角。那減少損失不重要么？當然重要，而且是極端重要。但是你怎么衡量減少的損失？沒有出現的損失不是損失，是無法估計的，無法變成活生生的統計數據擺在高層領導桌上的。三鹿出事情以前又有誰把質檢看得那么重要的？更可怕的是高層明知道質量有問題卻抱僥幸態度聽之任之。軟件行業里沒有么？很多項目經理掛在嘴邊的是：我的這幫伙計都有多年經驗了，活有保證的。
   
    對策：無。只有在業界摸爬滾打多年，吃了不少苦頭的企業才會刻骨銘心地知道質量才是生命線，靠說教是沒用的。作為個人只好良禽擇木而棲了。
   
    整個軟件工程體系發展相對滯后。IT領域發展極快，中國軟件業在商業應用上的快速發展顯然沒有得到理論科學的很好支撐。很多項目經理人都很年輕，是從程序員逐步成長起來的，缺乏對軟件工程，項目管理的理論修養和經驗，對技術和個人能力的迷信超過了系統的理論，對軟件產業的風險估計不足。測試往往是他們容易忽視的環節，因為在他們早期的項目實踐中缺少這方面的教訓。很多項目經理相信開發人員足夠應付日常測試，無需或只需很少的專職測試，這樣可以壓低成本。
   
    對策：無。隨著一批民族軟件中堅力量的成熟，科學理論的發展和實踐應用，情況會逐漸改善。
   
    從業人員相對能力的薄弱。多種原因造成。
   
    首先是上述兩大原因造成的大環境。哪個從業人員不想升職快加薪快。那他們在選擇職業分支時無疑會找"吃香"的。在論壇上的xdjm特別是男生，想一想你們有誰在讀大學的時候想著畢業要做測試的？這是一種惡性循環，軟件測試人員的待遇越差越少的人才愿意投身，越少人才，他們的地位越難提升。
   
    其次是學校教育的缺位。高等教育是批量造軟件人才的機器，這樣生產出來的人才象機器的零部件和容易組合在一起，因為他們有較接近的職業素養和專業風格。有人形容印度程序員寫出的代碼都是一張面孔的，為什么？因為在學校里有人告訴他們什么是好的編程風格，什么是項目的佳實踐，什么是完成一個模塊的一般步驟。中國大學有嗎？多少人是進了公司才知道注釋的風格規范的？高考的應試作文倒是有點像，可惜一無用處。
   
    再次是測試人員在工作中相對缺乏提高技術能力的機會。相對于開發人員，測試人員接觸新技術，或深入接觸成熟技術的機會相對較少，需要擠時間來學習。缺乏系統的學習過程和專人培訓。業余時間的自學效果遠不如在項目里邊做邊學來的好。這也是很多軟件測試人員很難從簡單操作型向技術型轉變的重要因素。
   
    還有一點是項目分工過細造成眼界過窄。qa的只管流程和整理文檔，不懂測試，測試的只管跑用例，不懂開發。軟件項目是個有機體，只看一塊卻不關注全局是很難適應未來的發展趨勢的。而開發人員在測試上的適應性顯著地比測試人員理解系統和代碼強。
   
    后一個很重要的因素是很多測試人員經常被綁在某一產品甚至某一模塊上很久。日久產生厭倦感或惰性。軟件人員重要的一項素質是廣博的知識面。但長期做一個或一種類型的項目顯然是不利于發展的。
   
    對策：
   
    多學多動手，多爭取實踐的機會。有很多機會老板既可以讓開發去做也可以讓測試去做（比如一些配置項目或者基于成熟框架的小代碼量開發）。假如你爭取過來不但有了實踐機會還可以借機顯示自己的能力。很多事情你只要專心去做一定能做好，不要猶豫，不要有顧慮，別人能做的你也能做。
   
    關注技術發展。 多關心前沿技術的發展， 多和技術大牛交流。 這樣可以拓展你的視野，很快提升總體技術能力和修養。 看過Jonathen Bach 的經歷明白多懂些技術術語對交流和工作是很有益的。
   
    多關注一些行業規范。 建議專著于某種編程語言，熟悉它的風格和規范，這會有助于理解代碼和靜態發現缺陷。也可以對開發提出某些建議，這也有助于提高自身在組織的地位。 還建議一定要熟悉uml常用的圖示。uml是軟件工程師的公共語言 .很難想象不懂uml你怎么跟其他人在系統層面交流溝通。
   
    有機會業余做些開發項目，或是參與一些開源的項目。 熟悉一般的開發手段和流程。
   
    學會一般的研究手段， 知道如何在網絡上獲得所需的信息。在很多情況下誰先獲得新的資訊誰牛。其實看一下國內很多所謂學術帶頭人的論文，也不過是比別人更早獲得國外的前沿信息，然后整理一下而已。能做一些研究的測試人員還是頗受歡迎的， 因為他們通常都能自己獨立地解決問題。 多留心收集一些好的網站是很有幫助的。
   
    后是調整自己的心理， 要敢于提出自己的想法和建議。要是你的建議能夠被采納當然可以提升你地位了。說不定還要你做專題的講座。 也要敢于據理力爭，但要有充分的準備。重要的還是要虛心向牛人學習。一個組織能夠生存必然有一些人發揮核心作用，從他們身上無論是技術還是其他方面都能夠學到很多很多。
   
    不知不覺寫得太長了， 確實這個題目擴展開來有太多的內容
   
    另外一位仁兄zdlzx的回答
   
    了解別人是如何看待你的：明確當前開發團隊和管理團隊對于測試是何印象和如何評價的。這里面好的方面固然要繼續保持和考慮如何做得更好，更重要的是不滿的方面，需要仔細分析落實如何改進。我看到的測試團隊有的并不能冷靜地全面接受負面的評價，或者過于夸大某幾個個別人的主觀評價而覺得明明自己沒有錯，因此不知如何改進。對于后面這種情況，其實溝通本身是改進的一個重要方面。
   
    思考自己該如何提高：不管別人是如何看待你的，我們都應該經常考慮從自身做起，如何進一步加強測試人員的專業性。很多的時候，開發團隊希望測試人員給出一些專業的判斷，比如：測試這個版本大概需要多少時間？當前版本質量的風險在哪里？性能測試如何建模才能真實模擬生產環境的使用情況等等。如果我們測試人員不能很好地回答這些問題，甚至在某些時候還出現過在這些判斷上的重大的失誤，會很大程度上抹殺他人對測試人員的信任和支持。有不同的觀點并不可怕，可怕的是沒有觀點或者堅持錯誤的觀點。因此我覺得不管別人當前對你或你的團隊評價如何，作為測試人員，你自己一定要堅持不斷地試圖在自己有話語權的地方不斷磨練準確和敏銳的判斷力。
   
   不要有"我們"和"他們"的意識。工作中，常聽到測試人員把測試團隊說成"我們"，把開發團隊說成"他們".這看上去是個小事，但實際上是很需要提醒大家注意的。余世維先生的管理課程里有非常精彩的一段關于小我的"我們"意識的批判。當測試團隊對開發團隊提出改進的要求或者建議的時候，請認識到每個開發人員也和你一樣聰明能干（一定有什么你不知道的原因使得他這個bug反復fail或者這個版本的質量很差），也請伸出你的手去提供一切可能的對方需要的幫助（即使那看起來不象是你職責范圍內需要做的），甚至是多一點寬容和耐心，也許比你義正言辭地指出對方的問題，不留一點情面要好一些。請時刻提醒自己在軟件開發團隊中你不可能獨善其身。請時刻反思自己：你有沒有總是從開發團隊/人員的角度去考慮問題，你能不能拍胸脯說你已經做到你能做的好了。
   
    一個軟件開發項目組，一個軟件公司，象一個大家。如果每個成員都能正確看待自己，不斷提高自己，多一些理解和友愛，那么也許我們不那么關注地位的高低了，因為你已經得到了一個win-win的結果：相互的尊重。