|
我將我的經歷寫出來,希望能夠給予眾多'環(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、前邊已經給領導灌輸過測試標準過低,影響公司產品質量的思想了;當然,咱也不能光說不練吧,那樣你將失去信任的.正好公司有一個項目級的項目,我就打算拿這個項目開刀,去驗證我所說的不足,于是和同事們協(xié)商過之后,決定選取該項目中的幾個模塊做'產品級測試'.測試結果就不描述了,在這個公司已經認為相對比較成熟的項目上,測出來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)協(xié)商這個問題需要解決時,他給我來了一個'不予處理'(因為這個模塊是他設計的,他說設計思路就是這樣~~)我說:'按照標準的話,這里我還是建議修改的.'他卻說:'你說的話就是標準??.'我當時就生氣了,我說:'我的技術不行,但是我會去參考人家的標準,并把人家的標準應用到我的工作中去.'不過,通過這件事情,也讓我意識到:我應該把'人家'的標準整理出來.于是,就去找總經理談話,建議在<公司測試工作管理辦法>上增加<測試標準>、<測試交接手續(xù)>,并得到了總經理的支持.當沒有'游戲規(guī)則'時,那么你就考慮制定出來'游戲規(guī)則',讓別人去遵守. 3.7、經過努力,我先后編寫了<測試工作(暫行)規(guī)范>、<公司測試工作管理辦法(與各部門之間協(xié)作模式)>、<界面測試標準>、<測試工作開始、結束標準>、<提交測試手續(xù)>等等.測試部在公司的地位也發(fā)生了改變-----既獨立于所有部門,又與各個部門展開協(xié)作,目的是測試工作絕對不能受任何外界影響. 3.8、最后,我想談一下工作方法問題.作為公司的一員,尤其是測試人員,必定要和其他部門人員打交道,不可避免的會發(fā)生一些意見不統(tǒng)一的事情.這個時候應該盡量避免正面沖突,畢竟你又不是對方部門的領導,人家也沒必要聽你的.但是測試人員要堅持原則性,這時候就需要你堅持把組織流程走完,之后,如果還沒有得到讓你滿意的結果,那么你就需要打一份報告,大概內容如下: A、對問題的統(tǒng)計數字; B、對問題的描述; C、對問題的危害性描述; D、對問題的開發(fā)人員意見; E、對問題的測試人員意見; F、聲明無論結果如何,測試人員保留原意見. 然后把這個報告拿到公司例會上,主送總經理,抄送各部門負責人.使命結束. 四、總結 以上是我在公司三個半月的工作經歷,盡管學習測試已經有一段時間了,但是真正能站到測試崗位上專職做測試也就這三個半月的時間.工作中的不足,還請大家指正.我之所以寫出來,一方面是給那些在'環(huán)境不理想'的公司工作的測試人員一點借鑒;一方面也是對自己工作的一個總結,讓大家來討論一下,以彌補自己在工作中的不足. 五、聯系方式 本人QQ:18902508,并組建了兩個測試群: 軟件測試交流（一）區(qū),群號:8568535 軟件測試交流（二）區(qū),群號:23602868 歡迎大家的加入,一起討論學習. 資源共享、信息交互、經驗交流，我們期望的是大家的共同進步！ 好久沒有來了,首先感謝大家的支持.告訴大家一個好消息,我在今年年初已經正式就任公司的測試部經理了,恭喜我吧! 鑒于好多朋友提出的需要我寫的部分資料的問題,說實話我也想拿出來,但是涉及公司的保密制度,我確實沒有辦法拷貝出來原稿.另外,把一個公司的管理制度應用到另一個公司去,顯然是不合適的,并且也是不實用的.因此,在這里我把編寫規(guī)范的提綱列出來,給大家一個參考思路.同時,把自己的編寫的體會拿出來和大家分享. 第一章軟件測試流程管理 第一節(jié)：軟件測試的術語定義 第二節(jié)：軟件測試工作總體流程 第三節(jié)：公司測試流程管理模式 第二章：測試階段性工作重點極其原則和標準 第一節(jié)：測試階段性工作重點 第二節(jié)：公司軟件測試的基本原則 第三節(jié)：公司測試的標準要求 第三章：軟件測試標準管理 第一節(jié)：軟件測試工作相關制度 第二節(jié)：公司項目的等級劃分極其測試標準 第三節(jié)：公司測試工具應用管理 第四章：測試工作實施與協(xié)作管理 第一節(jié)：測試工作實施對象及對象發(fā)布 第二節(jié)：測試工作實施流程標準 第三節(jié)：測試退出標準 第四節(jié)：Bug管理平臺的流程權限管理 附錄一：《軟件界面測試標準》 一、引言 二、界面標準. 2.1有效性檢查： 2.2易用性檢查： 2.3規(guī)范性檢查： 2.4幫助設施檢查： 2.5合理性檢查： 2.6美觀與協(xié)調性檢查： 2.7菜單位置檢查： 2.8獨特性檢查： 2.9快捷方式的組合檢查： 2.10安全性檢查： 2.11:多窗口的應用與系統(tǒng)資源檢查： 附錄二：《Bug等級劃分及響應》 附錄三：《軟件測試通知書范例》 附錄四：《需求變更說明書范例》 附錄五：《軟件修改通知書范例》 附錄六：《URTracker工具定制權限說明》 提綱有了,但是最關鍵的不是有多么完善的管理制度,而是管理制度有多少能夠被順利的執(zhí)行下去.沒有執(zhí)行力的管理規(guī)范,最多也就是一些文字而已.因此,建議在推行制度之前,一定要做好老板或者公司高層的思想工作,告訴他這樣做會有一定的風險,也會遭到一些來自開發(fā)部門的阻力,但是這樣執(zhí)行下去之后又會有什么樣的好處,改善公司目前的哪些不良現象或現狀等等.總之就是要找到一個強有力的推行制度實施的領導做你的后盾. 關于<第四章 測試工作實施與協(xié)作管理>的部分內容我整理到一個文檔中了,供大家參考. [ 本帖最后由 清風隨雨 于 2008-2-20 11:56 編輯 ] |
|
|
