我將我的經歷寫出來,希望能夠給予眾多'環(huán)境不理想'的測試工作者們一點借鑒,同時也請版主和經驗豐富的測試管理者指出我在工作中的不足. 我是三月一日進入公司的,至今有三個半月的時間,具體工作情況如下: 一、公司測試工作環(huán)境(剛進公司時) 我們公司在河南,和大多數河南的軟件企業(yè)一樣,測試工作都是開發(fā)的附屬工作,在公司里面,都是開發(fā)人員說的算. 二、測試組成員 我們目前的測試人員總共有四人,其中一個是行業(yè)專業(yè)人員(我們的部門經理),另兩個是其他專業(yè)的,我是唯一一個計算機專業(yè)并且接受過軟件測試培訓的. 三、工作經歷 3.1、剛進公司,當然要先熟悉公司軟件了,同時也要學習行業(yè)相關的業(yè)務知識,并開始熟悉公司的環(huán)境.(此時的我是多做少說話,因為畢竟是初來乍道,好多事情是禍從口出的道理我還是明白的.再說了,這個時候說話也沒資格啊,沒人聽哦! ) 3.2、在公司熟悉一段時間,和各個部門員工以及公司領導都比較熟了之后,就經常給領導們灌輸測試思想(當然不是介紹專業(yè)知識啊,說了也白說的).因為我們公司是做行業(yè)軟件的,所以需要開發(fā)公司自己的'產品'.因此,每當和領導談起測試工作的時候,我就問他們對測試工作有什么要求.當然,大多數的答復都是:只要不報錯就行.這個時候,我就把公司的'項目'分了兩個級別:產品級項目和項目級項目.然后告訴領導,作為項目級項目達到領導要求的標準當然可以了,但是公司是需要長遠發(fā)展的,必須要有合格的產品級項目才行啊!要達到產品級項目標準,僅僅是不報錯,是遠遠不夠的. 3.3、前邊已經給領導灌輸過測試標準過低,影響公司產品質量的思想了;當然,咱也不能光說不練吧,那樣你將失去信任的.正好公司有一個項目級的項目,我就打算拿這個項目開刀,去驗證我所說的不足,于是和同事們協商過之后,決定選取該項目中的幾個模塊做'產品級測試'.測試結果就不描述了,在這個公司已經認為相對比較成熟的項目上,測出來N多的問題,這是必然的結果. 3.4、測試結果出來了,我們測試組沒有選擇直接上報公司領導,而是從BUG管理工具里面選擇了一個比較類似的事物管理工具URTracker.把所有問題都上傳到這個工具上邊,并且把瀏覽評論權限分配給了所有的部門(以前僅技術部門內部通報,現在連辦公室、企劃部、市場部都參與進來了).這樣做的效果是十分明顯的,問題暴露出來之后才會得到客觀的評價,此時的非技術部門是測試部門的強力后盾啊.開發(fā)部門也找不到合適的理由來反駁我們,只能接受現實,踏踏實實的去修改他們以前不愿意修改的程序! 3.5、通過這件事情,公司領導也意識到了測試的重要性.公司總經理親自找我談話,讓我談談對目前的測試工作的看法.我在作了充分的準備之后,把公司的測試工作概括了以下幾點: A、測試計劃寫出來了,但是沒有按照計劃去執(zhí)行,那就是一張白紙,有那時間不如去執(zhí)行測試好了; B、沒有給予編寫測試用例充足的時間.老是程序開發(fā)完了才交給測試,并限制多長時間內完成.為了完成這樣的任務,測試部門就只能放棄編寫測試用例了,直接投入測試.但是這樣的效果又是什么呢?這樣的測試是可以發(fā)現一些問題,但是這是靠測試人員的測試經驗和專業(yè)經驗才發(fā)現的,在說明軟件質量是如何得到保障的時候缺乏有力的依據!這樣的測試是盲目的、隨意的、沒有計劃的,軟件測試的功能覆蓋率根本無據可查.結論只有一個----無效的測試! C、缺少用例評審制度; D、缺少對BUG等級的劃分; E、缺少對BUG的響應方式、響應時間的約定; F、缺少BUG的評審制度; G、缺少對測試過程的跟蹤制度;(咱不能光照別人不照自己,也得給自己部門提點建議) H、缺少獨立的測試服務器(測試和開發(fā)共用一臺服務器,暈了)、缺少.....(都是硬件設施,這里不提了) 當我把這些給總經理匯報之后,看的出來總經理的臉色已經變了.當即給了我一個任務:整理標準的測試流程、測試制度、管理方案結合公司現有技術力量和實際情況,制訂<公司測試工作管理辦法>(這點我比較慶幸,因為碰到了一個開明的老總,換個人估計會用各種各樣的理由來拒絕你,或者干脆認為你不切合實際). 3.6、剩下的事情就是按照上邊所說的逐一落實了.不過中間又出了一個小插曲.事情是這樣的:有一個問題,我認為它違反了易用性和一致性的原則,當我去找技術總監(jiān)協商這個問題需要解決時,他給我來了一個'不予處理'(因為這個模塊是他設計的,他說設計思路就是這樣~~)我說:'按照標準的話,這里我還是建議修改的.'他卻說:'你說的話就是標準??.'我當時就生氣了,我說:'我的技術不行,但是我會去參考人家的標準,并把人家的標準應用到我的工作中去.'不過,通過這件事情,也讓我意識到:我應該把'人家'的標準整理出來.于是,就去找總經理談話,建議在<公司測試工作管理辦法>上增加<測試標準>、<測試交接手續(xù)>,并得到了總經理的支持.當沒有'游戲規(guī)則'時,那么你就考慮制定出來'游戲規(guī)則',讓別人去遵守. 3.7、經過努力,我先后編寫了<測試工作(暫行)規(guī)范>、<公司測試工作管理辦法(與各部門之間協作模式)>、<界面測試標準>、<測試工作開始、結束標準>、<提交測試手續(xù)>等等.測試部在公司的地位也發(fā)生了改變-----既獨立于所有部門,又與各個部門展開協作,目的是測試工作絕對不能受任何外界影響. 3.8、最后,我想談一下工作方法問題.作為公司的一員,尤其是測試人員,必定要和其他部門人員打交道,不可避免的會發(fā)生一些意見不統一的事情.這個時候應該盡量避免正面沖突,畢竟你又不是對方部門的領導,人家也沒必要聽你的.但是測試人員要堅持原則性,這時候就需要你堅持把組織流程走完,之后,如果還沒有得到讓你滿意的結果,那么你就需要打一份報告,大概內容如下: A、對問題的統計數字; B、對問題的描述; C、對問題的危害性描述; D、對問題的開發(fā)人員意見; E、對問題的測試人員意見; F、聲明無論結果如何,測試人員保留原意見. 然后把這個報告拿到公司例會上,主送總經理,抄送各部門負責人.使命結束. 四、總結 以上是我在公司三個半月的工作經歷,盡管學習測試已經有一段時間了,但是真正能站到測試崗位上專職做測試也就這三個半月的時間.工作中的不足,還請大家指正.我之所以寫出來,一方面是給那些在'環(huán)境不理想'的公司工作的測試人員一點借鑒;一方面也是對自己工作的一個總結,讓大家來討論一下,以彌補自己在工作中的不足. 五、聯系方式 本人QQ:18902508,并組建了兩個測試群: 軟件測試交流(一)區(qū),群號:8568535 軟件測試交流(二)區(qū),群號:23602868 歡迎大家的加入,一起討論學習. 資源共享、信息交互、經驗交流,我們期望的是大家的共同進步! 好久沒有來了,首先感謝大家的支持.告訴大家一個好消息,我在今年年初已經正式就任公司的測試部經理了,恭喜我吧! 鑒于好多朋友提出的需要我寫的部分資料的問題,說實話我也想拿出來,但是涉及公司的保密制度,我確實沒有辦法拷貝出來原稿.另外,把一個公司的管理制度應用到另一個公司去,顯然是不合適的,并且也是不實用的.因此,在這里我把編寫規(guī)范的提綱列出來,給大家一個參考思路.同時,把自己的編寫的體會拿出來和大家分享. 第一章軟件測試流程管理 第一節(jié):軟件測試的術語定義 第二節(jié):軟件測試工作總體流程 第三節(jié):公司測試流程管理模式 第二章:測試階段性工作重點極其原則和標準 第一節(jié):測試階段性工作重點 第二節(jié):公司軟件測試的基本原則 第三節(jié):公司測試的標準要求 第三章:軟件測試標準管理 第一節(jié):軟件測試工作相關制度 第二節(jié):公司項目的等級劃分極其測試標準 第三節(jié):公司測試工具應用管理 第四章:測試工作實施與協作管理 第一節(jié):測試工作實施對象及對象發(fā)布 第二節(jié):測試工作實施流程標準 第三節(jié):測試退出標準 第四節(jié):Bug管理平臺的流程權限管理 附錄一:《軟件界面測試標準》 一、引言 二、界面標準. 2.1有效性檢查: 2.2易用性檢查: 2.3規(guī)范性檢查: 2.4幫助設施檢查: 2.5合理性檢查: 2.6美觀與協調性檢查: 2.7菜單位置檢查: 2.8獨特性檢查: 2.9快捷方式的組合檢查: 2.10安全性檢查: 2.11:多窗口的應用與系統資源檢查: 附錄二:《Bug等級劃分及響應》 附錄三:《軟件測試通知書范例》 附錄四:《需求變更說明書范例》 附錄五:《軟件修改通知書范例》 附錄六:《URTracker工具定制權限說明》 提綱有了,但是最關鍵的不是有多么完善的管理制度,而是管理制度有多少能夠被順利的執(zhí)行下去.沒有執(zhí)行力的管理規(guī)范,最多也就是一些文字而已.因此,建議在推行制度之前,一定要做好老板或者公司高層的思想工作,告訴他這樣做會有一定的風險,也會遭到一些來自開發(fā)部門的阻力,但是這樣執(zhí)行下去之后又會有什么樣的好處,改善公司目前的哪些不良現象或現狀等等.總之就是要找到一個強有力的推行制度實施的領導做你的后盾. 關于<第四章 測試工作實施與協作管理>的部分內容我整理到一個文檔中了,供大家參考. [ 本帖最后由 清風隨雨 于 2008-2-20 11:56 編輯 ] |
|