當(dāng)前位置:工程項目OA系統(tǒng) > 泛普各地 > 黑龍江OA系統(tǒng) > 哈爾濱OA系統(tǒng) > 哈爾濱OA快博
軟件測試工程師如何與開發(fā)工程師交流
作為測試工程師,在日常工作中接觸最多的當(dāng)然是團隊中的開發(fā)工程師,如何和開發(fā)工程師進行有效的交流是測試工程師面對的 重要問題。一般來說,在一個團隊中,總是有開發(fā)人員喜歡和不喜歡的測試工程師,這兩者之間的工作效率和效果都有很大的差異。當(dāng)然,不能武斷地說測試人員不 喜歡的測試工程師就一定是效率低下的測試工程師,或者說是不合格的測試工程師,但一般來說,那些容易得到開發(fā)人員認(rèn)可的工程師在測試時總能夠更好地發(fā)現(xiàn)缺陷和敦促開發(fā)人員解決缺陷。
測試工程師和開發(fā)工程師承擔(dān)的是開發(fā)工作的兩個不同方面,說得極端一點,一個是創(chuàng)建,一個是破壞,雖然兩者的 最終目的都是一樣的,但在達(dá)成目標(biāo)的方式上卻有很大的差異。因此,在為同一個目標(biāo)奮斗的過程中,發(fā)生沖突也是難免的,但通過下面的一些建議,換個視角看看開發(fā)人員的生活和工作,可能很多的沖突就能化解于無形了。
Cem Kaner在《Testing Computer Software》書中有一段話: “The best tester is not the one who finds the most bugs or who embarrasses the most developers. The best tester is the one who gets the most bugs fixed.” (最好的測試人員不是發(fā)現(xiàn)最多BUG或是使得最多開發(fā)人員不自在的人,而是能夠[說服開發(fā)人員]修正最多BUG的人),建議大家好好理解這句話。
至于我個人,是從開發(fā)工程師轉(zhuǎn)為測試工程師的,對于開發(fā)工程師的處境和想法也曾有過切身的體會,或許是這個原因,讓我在和開發(fā)工程師交流的過程中還算是比較 順利,和他們相處得也還不錯。在我的測試經(jīng)歷中,也接觸過相當(dāng)多的開發(fā)工程師,這里我把和開發(fā)人員交流的經(jīng)驗歸結(jié)為“五要四不要”:
1、要耐心和細(xì)心
細(xì)心是測試工程師的一個基本素質(zhì),測試工程師是對質(zhì)量負(fù)責(zé)的人,涉及到質(zhì)量問題,就不能含糊,因此一定要細(xì)心,細(xì)心對待每一個可能的BUG、細(xì)心對待每一段 被你檢查的代碼,細(xì)心對待每一個你撰寫的BUG報告,細(xì)心對待你發(fā)出的每一封郵件。細(xì)心是一種態(tài)度,你的態(tài)度遲早會感染和你合作的開發(fā)人員,而這往往是合作愉快的基礎(chǔ)。
至于說到耐心,在我的工作經(jīng)歷中,不厭其煩地向開發(fā)人員解釋一個BUG,讓他認(rèn)識到BUG的重要性是經(jīng)常的事情,其實想想也很正常,對任何人來說,被人指出自己的缺點和不足都不是讓人舒服的事情,因此,一點不耐煩的情緒就可能引起對方很大的反感,給自己的工作帶來不必要的麻煩。
2、要懂得尊重對方
開發(fā)是一件需要全面和綜合考慮的工作,開發(fā)工作中,由于各種原因?qū)е鲁绦蛑谐霈F(xiàn)問題是很正常的現(xiàn)象,作為測試工程師,發(fā)現(xiàn)了這些問題并不值得你夸耀,也不能 說明你比開發(fā)工程師聰明。一個好的測試工程師一定是懂得尊重開發(fā)工程師的人,尊重對方的技術(shù)水平,尊重對方的代碼。我接觸過的開發(fā)人員都是挺和善的,一般來說,對他們最大的尊重就是承認(rèn)他的專業(yè)水平,承認(rèn)他的代碼。對他們來說,代碼就像是自己的孩子一樣:)因此,記得在合適的時候表達(dá)你對他的尊重,贊揚一下他代碼的精妙之處。
3、要能設(shè)身處地為對方著想
開發(fā)工程師一般都處在較大的工作壓力下,他的上司直接考核他們的指標(biāo)很大程度上是已完成的代碼,所以在工作任務(wù)緊張的時候,對于測試工程師報上來的BUG會 拖延解決甚至是推脫,給測試工程師的感覺就是很不合作。那么在這個時候,就需要設(shè)身處地的為對方著想了,每個人都會為自己的工作在內(nèi)心排定優(yōu)先級,如果他 認(rèn)為解決你發(fā)現(xiàn)的BUG不是重要的事情,那么最大的可能就是你并沒有向他解釋清楚這個BUG的嚴(yán)重程度。發(fā)現(xiàn)BUG是我們的責(zé)任,敦促BUG得到解決是我們更重要的責(zé)任,因此,我們可以心平氣和地和開發(fā)人員坐下來討論一下BUG的嚴(yán)重程度,和他一起排定BUG的優(yōu)先級別并確定解決的時間。
4、要有原則
不要忘記,測試工程師需要對產(chǎn)品的質(zhì)量負(fù)責(zé),在這一點上一定要有原則。測試工程師可以和開發(fā)工程師建立良好的個人關(guān)系,但在具體的事情上,一定要按照公司的 相關(guān)流程來處理。當(dāng)然,在堅持原則的同時,可以采用一些委婉的表達(dá)方式,可以在允許的情況下盡量體諒開發(fā)工程師,但請記住,一個有原則的測試工程師才能真 正幫助開發(fā)工程師,才能贏得開發(fā)工程師的尊重。
5、要主動承擔(dān)
如果開發(fā)工程師要求你承擔(dān)部分不屬于你的責(zé)任,比如,定位你發(fā)現(xiàn)的BUG到代碼一級,或者是幫助他編寫部分文檔和代碼(不要不相信,真的有這樣的事情),那 么你會怎么做呢?在我的測試經(jīng)歷中,這些事情都遇到過,我的原則是在可能的情況下盡量多承擔(dān)。其實都是工作上的事情,有能力的話,多做一點也無妨。當(dāng)然, 肯定有人不同意我的意見,在這里我也不想爭辯,個人意見而已,僅供參考:)
在我的測試經(jīng)歷中,我會根據(jù)自己的進度和時間安排盡可能地提供更多的關(guān)于BUG的參考意見,甚至是定位到代碼一級,這種方式不是正規(guī)的方式,但對于提高自己被信任的程度是非常有益的。但在主動承擔(dān)時,一定要明確是在自己確有余力的情況下才能去承擔(dān),否則,婉拒是最好的對策。
【四不要】
1、不要嘲笑
不要嘲笑你所發(fā)現(xiàn)的BUG,即使是非常愚蠢的錯誤也絕對不要嘲笑,說不定那個錯誤是因為開發(fā)工程師聯(lián)系加班24小時犯下的,對別人的工作始終應(yīng)該尊重。如果 你覺得有必要提醒他不再犯一些經(jīng)常犯的錯誤,可以采用這樣的方式:編寫一份測試過程中發(fā)現(xiàn)的開發(fā)人員常犯錯誤的文檔(記住,千萬不要寫上誰犯了這些錯 誤),用輕松的口氣調(diào)侃一下,發(fā)送給開發(fā)人員。這種方法我采用過,開發(fā)人員都能很快接受。
2、不要在背后評論開發(fā)工程師
永遠(yuǎn)不要在背后評論開發(fā)工程師的技術(shù)能力,這個絕對是非常忌諱的事情,一時的口舌之快或許會使你永遠(yuǎn)不再能同他良好地合作,要知道,開發(fā)工程師最在意地就是別人對他的技術(shù)能力的評價。其實這個不僅僅是作為測試工程師的準(zhǔn)則,也應(yīng)該是做人的準(zhǔn)則。
3、不要動輒用上層來壓制對方
在出現(xiàn)和對方的意見分歧的時候,應(yīng)該采用什么方式說服對方呢?直接向上層求助當(dāng)然是一個辦法,但這種辦法帶來的負(fù)面左右也是很明顯的,首先是作為上層的處理 結(jié)果可能不一定符合你的愿望(在很多公司,開發(fā)工程師的地位高于測試工程師的地位,這種地位的不平等導(dǎo)致上層在處理分歧時會有一定的偏向性);其次是動輒 拿出上層來壓制對方只能給他人留下無用的印象。所以在出現(xiàn)分歧時,盡量嘗試通過溝通解決吧,實在不行,再動用最后的手段。
4、和開發(fā)人員的溝通不要只有BUG
除了在BUG記錄單上,在其他的地方也讓和你合作的開發(fā)工程師接觸到你吧:),午餐或是集體活動的時候多和對方聊聊天,一方面可以增進彼此的感情,混個臉 熟,打交道的時候也方便;另一方面,從他那里了解業(yè)務(wù)的知識和他負(fù)責(zé)模塊的方方面面,對自己也是提升。我個人就很喜歡和開發(fā)工程師溝通,開發(fā)工程師其實一 般都是比較健談的,尤其是對自己程序的精妙之處,多了解一些,多接觸一些,對自己總是有益的。
寫了這么多,其實關(guān)鍵的就是兩點:多從別人的角度去想想,所謂“換位思考”,多尊重對方就一定能得到對方的尊重與配合;其次是加強和開發(fā)工程師的溝通,讓他清楚地認(rèn)識到你的工作對他的價值,你發(fā)現(xiàn)的每一個BUG的重要性。
我一直認(rèn)為,一個好的測試工程師一定是在公司里被所有人尊重的快樂分子,而不應(yīng)該是一個“鐵面判官”:)當(dāng)然,作為我個人來說,絕對不敢說自己做的已經(jīng)很好了,不過,我經(jīng)常都記得提醒自己:尊重對方。
來源:軟件工程專家網(wǎng)
- 1企業(yè)CIO在OA方面只能有三種選擇
- 2XML解決利用數(shù)據(jù)難題
- 3反思競爭情報系統(tǒng)建設(shè)中的十大疑慮
- 4移動商務(wù)價值七個參與方
- 5按層次討論信息系統(tǒng)對信息需求的支持能力
- 6知識管理是一種持續(xù)的實踐
- 7給績效管理一個寬容的環(huán)境
- 8日企的本地化的信息系統(tǒng)建設(shè)
- 9跨國企業(yè)最需要的十個IT策略
- 10掀開幕布看PDM:產(chǎn)品數(shù)據(jù)管理系統(tǒng)的概念與應(yīng)用
- 11美國國家半導(dǎo)體如何進行知識管理
- 12信息化互動式實現(xiàn)系統(tǒng)與企業(yè)的適應(yīng)
- 13IT經(jīng)理如何控制系統(tǒng)項目中的風(fēng)險
- 14KM助力企業(yè)應(yīng)用員工的智慧
- 15哈爾濱有OA軟件的代理嗎?要支持服務(wù)的
- 16“無線”模式也可繞道快行
- 17向Linux遷移的用戶移植分析
- 18如何做需求開發(fā)?
- 19從泰坦尼克中汲取的IT項目教訓(xùn)
- 20萬邦藥業(yè)IT舊債是否真的難還
- 21小資料:不同類型的知識管理系統(tǒng)
- 22下一代流程管理的夢想
- 23KM實踐:亞信剛性和柔性的平衡
- 24OA辦公系統(tǒng)和Web服務(wù)是獨立于編程語言的
- 25如休運用AHP法篩選“物流服務(wù)供應(yīng)商”
- 26業(yè)務(wù)流程建模的人員、流程和項目移植
- 27供應(yīng)鏈中的“孫子兵法”
- 28城域以太網(wǎng)跨越障礙
- 29知識管理:1公里還是1,000米?
- 30網(wǎng)絡(luò)技術(shù):源特定組播網(wǎng)絡(luò)技術(shù)
成都公司:成都市成華區(qū)建設(shè)南路160號1層9號
重慶公司:重慶市江北區(qū)紅旗河溝華創(chuàng)商務(wù)大廈18樓