把BBS的文章拿來總結一下。有的公司很正規，不需要測試直接同開發人員進行打交道。但是對於規模較小的項目團隊或者處於起步階段的公司里面的測試人員來說，與開發打交道是一件不可避免的事情。
當處於這種狀況時，如何和開發打交道更多的是一個溝通的技巧。
超越自我says:
首先,要確保自己能重現BUG的過程;(要真正能模擬到該問題的存在)
其次,要將系統出現BUG給用戶帶來的影響要逐一解釋和說明,讓開發人員真正了解問題的所在,也節省開發人員的時間,
並分析系統存在瓶頸會引起更多問題,
再次,也要分析修改BUG后,將會帶來什么問題,用戶是否可接受?並要把修正BUG所引起的問題減少,
而不是增加另外的BUG,而通過自己對系統的熟悉程度,開發人員
也會對測試人員提交的BUG引起足夠的關注度和重視,從而讓BUG徹底解決,
最后,通過開發人員對BUG的修正,自己也進行一次回歸測試,讓開發人員覺得測試人員是對質量的負責,而不是針對開發人員,以便利於下一次問題的提交和修正!
總之:測試人員是對產品質量,而不是針對某一個人,而且也要把BUG及時提交,不要錯過提交BUG的最佳時間,
因為BUG越不解決,積累的問題越多!
所以測試人員要對發現BUG要有信心和足夠的時間重現BUG,讓產品更具有質量性!
maguschen says:
1.把自己的Bug Report完善；有時候開發看到一些莫名其妙的Bug Report會很生氣，這樣首先就影響了你在他心目中的印象，要讓別人改正，首先要保證自己是正確的、完善的。
2. 對事不對人；找開發的時候應該針對具體的問題，可以用“我們的軟件出現了這樣的問題”，而不要說“你這里寫的不對”。
3. 擺事實；對於具體的bug，可以給開發說明一些事實，例如某個樣式問題其實十分影響用戶體驗。
4. 挖歷史；如果以前有類似的問題，可以把那個問題，以及造成的后果給開發闡述一下。
5. 平時跟開發拉好關系
6. 把更高層的人拉進來；很多時候都是公說公有理婆說婆有理，這時候就需要一些第三方的同事來幫忙，這個人通常要是能說事的才行，例如研發總監或者項目經理，但是主要不要讓人覺得狐假虎威的感覺，這招不適宜經常用。
男孩子 says:[正規的公司做法:]
感覺之所以提出這個問題，是因為公司的體制根本就不完善。
測試人員的職責是測試，研發人員的職責是研發，測試人員提bug，研發人員改bug，誰賦予了測試人員去督促研發人員修改bug的權利了？測試人員又有什么義務去督促研發人員修改bug呢？
之前跟一個在NEC工作的哥們聊過，在他們單位，測試人員是不直接跟研發人員打交道的。測試和研發中間有個中間角色，我們暫稱其為bridge。測試人員的bug提交給bridge，bridge鑒定其是否為bug，是bug，流轉給研發，不是bug，駁回給測試。同樣道理，研發人員如果reject，也是由bridge與其交流。當然，bridge不是隨便抓個人就可以當，級別得相當於“技術總監”吧。
當然，目前接觸的好多單位都把這個角色省掉了。一個產品或者項目的測試可能總共也就2-3個人，怎么舍得派這么個大牛給大家呢？所以題目描述的問題又是一個不得不面對的事實。
從我的經驗來看，出現這樣的情況通常不是一些重要的bug，所以測試人員應該盡量將自己的bug描述的細致清晰，然后將bug轉交給項目leader處理或者留在評審會時討論，而不應該跟研發人員在這個問題上做過多的爭論，這樣一來耗費時間，而來會影響在后續工作中的合作。
研發人員因為在開發技術上的優勢，常常會對測試存在一定偏見，測試人員應該能夠認識並理解這一點。
樂游 says：
如果我認為這個bug更多的是從技術角度考慮，需要修改的，那么我會把SA引入到對這個bug得判斷上來，由SA決定這個bug是否需要修改。
如果我認為這個bug更多的是從用戶角度考慮，需要修改的，那么我會把CS引入到對這個bug得判斷上來，由CS給出這個bug是否需要修改的建議。
最后，如果說這個bug得發現是在項目的敏感期（大部分都是項目后期，接近release的時候）f發現的，那么我會直接找到PM，告訴PM這個bug得相關情況，然后請PM決定是否需要修改這個bug.
sun_0910 says:
1. 扭轉研發領導的思想，提高研發人員的響應速度：
a). 讓研發團隊的領導重視缺陷：
很多研發團隊的領導都是銷售出生，懂技術的很少，他們和搞技術的想法明顯不一樣。我在的第一家公司，發布版本時很多時候，都是沒有測試結束，功能開發的差不多就把產品賣掉了，后面再對版本不斷升級，結果這個公司沒多久大概3年不到就散伙了。后面一家公司的領導是做質量管理出生的，明顯對測試的質量要求就不一樣，每次要求都特嚴，對以前測試結束標准都做了進一步的修改。如果領導對缺陷都視而不見，你說研發人員還願意花大量的力氣去修改Bug嗎？所以說，團隊的領導的想法或意識，對缺陷是否修改起到非常重要的作用。我記得以前測試高手zhuzx也在每周一問中提到過，大家也可以借鑒一下。
b). 采用常用的缺陷管理工具（QC9.0），提高缺陷的透明度：
我們公司使用缺陷管理工具（QC9.0）,測試經理任管理員，給公司高層領導、項目經理、開發經理都分配了權限，自己可以登錄系統查詢相關信息。在測試后期，特別是要發布版本前后，領導們一有空，也隨時上去瀏覽一把，無意識給開發人員施加了較大的壓力。如果這個時候還有很多Open的缺陷，開發人員自然不敢怠慢。
c). 把開發人員的修改缺陷的響應速度，記入績效考核內容：
由於公司總監特別關注產品質量，我們公司對缺陷修改這一點做得比較好，每次都是遞交缺陷以后，開發人員響應特別快。如果有疑問，就馬上和測試人員一對一交流，盡快修復或解決該缺陷。 我們公司的口號是：“寧願花出100倍的代價，也不讓發現的缺陷留給客戶”。還有一點就是開發人員績效考核的時候，我們測試人員要給開發人員打分，很重要的一點就是：開發人員對測試缺陷的響應速度，如果這一項很低的話，老大要找你談話的，問具體原因是什么？呵呵。所以，我們公司很少有測試人員追着開發修改缺陷的情況，把修改缺陷的響應速度納入個人績效考核，我個人覺的是一種比較好的方式，值得借鑒或推廣。
2. 組建一個合理的研發團隊，規范測試規范：
a). 關鍵是建立一個完善的研發機制：
在大多數情況下，是不是軟件缺陷或者需不需要修改，怎樣修改不是測試人員和開發人員說了算的，應該是靠研發部門的相關制度或相關部門去約束。畢竟在國內軟件的軟件企業缺少這樣的部門，所以說把修改缺陷相關的重任推到了測試人員的頭上，其實對測試人員實在是太不公平了。要解決這個問題，最關鍵就是建立一個完善的研發機制，讓QA等相關部門督促解決這類問題，比較好。
b). 分清團隊成員的具體責任：
對於研發團隊中的每個成員，必須責任明確，否則像督促缺陷修改這樣的事情本來不是測試人員的責任，現在都推到測試人員頭上了。很郁悶！！
c). 完善測試規范，明確Bug管理制度：
大部分的公司，都沒有單獨的部門來單獨管理督促缺陷是否修改，都默認為是測試部門的事情。個人覺的最好是賦予項目組中相關人員一定的資質，讓他們去處理這些瑣事。經常碰到這樣的情況，很多爭議的缺陷都一直放到后面一個版本，一段時間下來，幾個版本爭議的缺陷就多於100個，弄得后面版本也不好發布。我們的做法是，發布前幾天，對每個爭議的缺陷用郵件先發給項目組成員先看，后面在召開缺陷評審會議，如果通過，毫無疑問修改，否則關閉或保留到下一個版本。
3. 從源頭上杜絕無效缺陷的遞交：
a). 測試前細化測試需求,避免遞交歧義缺陷：
很多研發不願意修改的缺陷，大部分都是由於需求不明確或者理解歧義引起的。所以，最好的做法是在測試以前，開個項目會議，細化一下測試需求，讓研發去確認或項目組成員集體Review，達成一致觀點。盡量減少理解上的歧義，力爭盡早消除無效或爭議的軟件缺陷，避免遞交的缺陷成爭議的缺陷。測試人員無法說服研發，讓研發去修復缺陷，長期這樣，測試部的威信就大大降低了。
b). 把握不准的缺陷，遞交以前最好討論一下：
特別是在測試初期，由於測試介入項目時間較短，有時候測試人員對業務或需求了解不深，遞交錯Bug也是常有的事情。這個時候，往往測試認為自己遞交正確了，開發人員認為自己開發軟件是對的，互不相讓，如果處理不好，很容易弄僵關系，弄得大家都不是很愉快。要是項目中出現這樣的Bug，是很難說服研發去修改的，還有可能成為研發抓你的“小辮子”的有力證據，要是這樣以后就更難做了。個人的一些做法：所有的測試缺陷相互審核后，才遞交到缺陷系統上公開，是最為保險的方法。
c). 清楚無歧義的描述Bug，減少隨機測試，帶來不可重現的Bug：
很多時候，測試人員把缺陷描述不清楚或者缺陷有歧義，開發人員看不懂，不明白具體的意思，加上開發人員任務重時間緊，很容易產生逆反心里，這就讓開發人員對測試人員有看法，以后遞交的缺陷認可度就大大降低了。還有就是要減少隨機測試，一定要保證遞交的缺陷能夠重復出現，最好要有截圖、圖片或者用數碼相機照下來，讓開發人員認識到這個問題確實存在，並且更具說服力。
d). 做好版本配置管理工作，保證測試環境的准確性：
很多同事發現的缺陷，只有在測試環境下重現，而在開發環境下不能夠重現。這樣的缺陷開發人員往往是看不到的，他們很容易得出結論，說測試人員遞交無效的缺陷而被拒絕，大部分情況發現是版本弄錯啦！！我們唯一能做的就是做好源代碼的配置管理工作，保證測試環境版本的正確性和獨立性，自己編譯自己部署測試環境。只有這樣，才會減少無效缺陷的遞交，避免“費勁周折”說服開發人員修改缺陷。
4. 正確分析測試中的軟件缺陷：
a). 為遞交的每個缺陷准備幾條充足的理由：
一般情況下，我們提到一個Bug時，開發人員都會說出很多可以不修改缺陷的理由，盡量搪塞住我們的口，要求我們關掉缺陷或者置為無效或者延期到下一個版本。如果你很牛，你可以為自己遞交的每個缺陷准備很充足的理由去說服開發人員；如果你不是太強，那就可以求助部門同事，集中測試部門團隊的力量，想一些好的、站得住腳理由，詳細介紹給研發人員聽，只要我們遞交的Bug，每個都具說服力的話，我想他們也會盡快修改的。這種方法還真是不錯，大家不妨試一試。
b). 詳細分析缺陷給項目帶來的各種可能影響或缺陷風險：
比如說，我們遞交一個缺陷，如果研發的覺的這個缺陷可以修改或可以不修改時。我們一定要給研發分析修改這個缺陷的必要性，不修改，對客戶帶來哪種可能影響或存在哪些風險。要在修改缺陷的代價與修復成本的關系上去衡量。相信，當我們對缺陷分析的很詳細時，研發人員一定會修改Bug的。
5. 做一個聰明的測試工程師：
a). 注意和研發人員的溝通技巧：
如果測試人員沒有做過開發工作，理解也許就比較片面。有的測試人員，對待問題沒有耐心，性情比較急，也是常有的事。如果沒有較好的溝通技巧，也許就是幾句話的功夫，就和同事爭吵了起來，弄得大家都比較尷尬。個人建議：談話時，要注意溝通技巧，要有換位思維的方式，做事情對事不對人，處理事情一定要有一顆寬容的心。只有這樣，才能夠很好的說服研發去修改Bug。
b). 和研發人員搞好私人關系，做研發的聽眾：
比較明智的測試人員，一定要學會傾聽研發人員的心生。很多時候，開發人員碰到工作困難的時候，很希望和人傾述，如果測試人員是他的聽眾，那么你們的關系一定會不錯。搞好了私人關系，工作中你遞交的缺陷，他們就不會那么斤斤計較了，畢竟關系是基礎，關系好了好說話呀，在中國就是如此。如果私人關系好了，說服研發修改Bug就是很容易的事情。不過得提醒一句：不能因為關系好就把Open的缺陷給關了。
6. 抓住時機，不要錯過千載難逢的好機會：
a). 求助公司上層領導：
很多時候，測試到后期，開發人員把缺陷也修改的差不多了，公司領導（比如說老總、總監、項目經理或開發經理）就會隨時來測試部門，找測試經理或負責人了解項目測試的具體情況。如果有一些問題都是爭議問題，作為測試Leader的你不妨給領導聊聊，把更高層的人拉進來為測試部門說話，為測試部門撐腰，但是凡事都有一個度，不能太過分，否則很傷同事的和氣。
b). 要求客戶代表援助：
很多GUI的缺陷或可改可不該的缺陷，可能作為客戶使用不是很方便。我們可以和客戶代表聊聊這樣的缺陷，如果客戶代表同意這樣做，那沒問題，可以不修改；如果客戶不同意，他自然會直接找項目經理或高層人員協調解決這個問題，這就不用我們測試人員操心了。因為客戶就是上帝，這招不錯吧！！！
yetties2005 says:
自己的BUG要定義明確.告訴自己那是個BUG.跟開發談的時候別人家一說什么你就想這到底是不是BUG啊,是不是自己錯了.千萬別有這樣的想法,就算有,也不要在跟人談的時候出現.還有就是通過需求.說明BUG不改客戶是不能接受的.在就是像前面所說的.要軟硬兼施
coffeg says:
據我個人的經驗主要是下面幾點：
1.bug本身的質量。這個非常重要，如果是嚴重的bug不用去說服，研發自然會去修改。
2.bug會產生的影響。這個考驗測試人員的功力了，並不是要誇大bug的嚴重性，而是你有沒有比開發看得更遠。比方說是一個驗證框顏色的bug，開發認為可改可不改，但你如果能說出如果用戶是色盲就無法看清楚，也就無法登陸，進而無法使用我們的服務，而且中國色盲的人數是多少這么一報，那么他肯定得改。
3.對自己的能力的認同。需要說服的bug本身就存在爭議，確實也存在可改可不改的bug，你如果認為確實需要改，就一定得堅持，找到充分的理由，然后在評審中一擊必中，確立自己在研發心中的形象。就是說你發現的bug基本上在評審上都需要回去反工的，以后不用你自己說，他們自己就會去改了，也不存在什么說服了。
4.提升自己的能力。如果說前三點是技巧，最后一點可就是基礎。開發人員和測試人員都是這樣子，雙方都有一個比較，讓他們覺得在測試這塊你就是權威你的能力起碼不能比他們差，就算是沒參與編碼也需要一看就知道大概是他們會是怎么做的，通過少數幾個問題即可知道問題容易產生的地方。
總的來說我個人覺得沒有說服的bug，主要看你是否有充足的理由，和合理的方法。當然公司的評審制度也需要有，沒有這個話完全靠測試個人是不行的。
吳如領 says:
讓開發心甘情願的修改BUG，我們可以從下面幾個方面來考慮：
一、為什么定為BUG
- BUG描述------測試員在提出BUG時，要注意對BUG進行必要的描述，例：BUG出現的環境、出現該BUG進行的操作、預期結果和實際結果、BUG出現的幾率，如果使用的BUG管理工具的允許，可以對該BUG添加一些附件：截圖、腳本等，Jira、Lotus好像都可以添加附件。一方面增加開發對BUG的閱讀、定位，另一方面能通過有利的論據證明該問題是BUG
- BUG復現------提交BUG后要保證BUG復現，這樣在項目經理、測試經理、開發人員爭論BUG時，能強有力的證明該BUG是存在的。
- BUG依據-------理論上，產品中不滿足用戶提出的需求就可以定為BUG，這也是測試前期進行需求評審的原因。但是，目前很多公司的軟件項目對其中的細節描述很不具體，導致了開發與測試關於BUG的歧義。在定BUG的時候我們可以本着這樣一個原則：和當今流行產品做對比，比如說公司在做個搜索引擎，開發將搜索引擎的位置放在頁面的底部，我們就可以說這是一個BUG。理由很簡單，百度、google的搜索框都在頁面的上部。
二、測試經理對BUG的認同
- 測試經理的經驗-----測試經理一般來說都是工作幾年，有相當豐富的項目經驗，我公司測試人員提出的BUG，一線的測試經理都要審核，審核通過才轉到項目經理，這樣避免了由於測試員工作經驗不足和個人主觀意願導致BUG錯誤認定的情況。
- 測試經理的信賴-----測試經理對BUG認同后，也就說明了該問題是BUG，在后續的爭論中不會出現測試經理搪塞的情況，對測試人員也是非常有利的。
三、有效的溝通
- "犧牲色相"-----該方法要求測試人員為了工作，主動和開發建立良好的關系。譬如：請開發吃飯等等，這種方法最有效，也是百試百靈。但個人不建議這么做，工作就工作，耍手段是不好滴。
- "良好的同事關系"----這種方法要求測試和開發平等的地位，測試要本着"我的工作職責就是讓軟件運行的更好"，通過合理的溝通手段，讓開發能認同自己的觀點，並進行BUG的修復。不要因為自己對技術了解不如開發深，就不敢提問題。
- "強調BUG的影響"----溝通中提出修改BUG帶來的好處，不修改BUG將要導致的問題，讓開發明白問題的嚴重性。那怕是用戶體驗的BUG，也可以借助用戶的場景，說明修復BUG的必要性
四、利用身邊的資源
- 上級領導-----借助測試經理和項目經理，有時候個人不能協調解決的問題，就不要逞強，讓測試經理和項目經理來協調，切忌不要悄悄的在項目經理面前說開發的壞處，大家都是打工的何必呢，況且不一定能起到作用。要記住--自己找項目經理和測試經理是協議矛盾的，解決問題的。
- 部門例會-----很多公司，每周或每月都會進行部門例會，方便各個部門間交流溝通，可以由測試經理反映下最近測試情況，測試員發現多少BUG，開發修改多少BUG，遺留多少BUG。如果通過公司的運營了解到，用戶也出現了遺留BUG中的問題，那更好。通過數字讓公司認識到測試的重要性，那么以后BUG的修復工作就更好進行。
- 公司制度-----在國內以前測試員的績效考核往往是有開發組長來評分，現在很多公司都做到，通過測試發現的BUG數、BUG嚴重程度來衡量開發人員的工作水平，這也能促進測試工作的開展
- BUG管理平台------目前，國內對BUG管理平台的使用還不成熟，個人見到過口述BUG的、紙制BUG單等等，個人不贊同這么做，口述BUG和紙制BUG單保留時間有限，對於有自己產品的公司，歷史的BUG很有參考價值。確定BUG時可以拿出以往的BUG庫做參考。
總結，個人只提出一些實際工作中的經驗，也建議大家在工作中學習，不要只看大道理，在特定的環境中掌握的技能才是根本。呵呵，以上是自己的一些想法，希望大家都提出寶貴的意見。
fairy_lu says:
我認為，測試人員應該很明確的記錄這個bug，然后查看設計中是否有相關的設計，如果是設計中有而開發人員沒有實現，那么就拿着設計文檔和開發人員談。如果設計中沒有，就看需求中是否有相關內容，如果有就要找項目經理來看，是不是需要在設計中加入這一塊內容。如果需求中都沒有，但是測試人員仍舊認為是一個bug，那么就應該找項目經理談，由項目經理決定是否確認其為bug，是否需要修改。總之，不能夠隨意放過任何一個測試出來的bug，也不能夠和開發人員弄僵關系。我們應該讓他們知道，我們做的一切都是為了項目能夠更好的完成，而且就算我們找來項目經理討論，不是打小報告，而是找來比較權威的人士來做決策。
zengyixun says:
由於我做過兩年的開發，5年的測試，在測試過程中，自己也做過些測試工具，也有測試人員對我的測試工具來進行測試的經歷，所以我首先站在一個開發人員的角度來看，什么樣的bug與測試人員能說服我呢？要說這個問題，我們首先要有有一個假定：假定開發人員不是一個神經病（多數其實都不是，如果是，那么應該由人力資源部負責），既然開發人員不是神經病，那么你一定要相信他對於自己所做的模塊也是抱着認真負責的態度，希望把功能順利實現，而不會出現什么意外狀況的，所以當有人給我提出一個bug是我確實沒有想到的，而又實在的影響到這個模塊的功能，我做為一個開發人員會考慮修改這個問題，如果這個問題還有一點點深度，我會更加開心，抱着挑戰的態度，也抱着趕快把此功能搞定的急迫心情去修改它，由此得到一個好的績效與認同，所以像這樣的bug，需要測試人員來說服我么？當然不需要。然后再看看什么樣的問題我不喜歡，曾經我做過一個測試工具，新來的測試人員對我的工具進行了測試，在測試的同時，也使新人學習了各種業務知識，在這些測試者中，我就很明顯的對那種能提出功能性錯誤，或者我考慮不周造成的錯誤（這一定要用專業的測試方法才能測出的）的新人，我會報着一種對他的欣賞的態度去修改他提出的問題，而對那些，沒事找事，總是按自己的主觀意願提出一些使用上問題的人，給以鄙視，比如新來的測試負責人，在我修改完所有問題后，叫我把下拉框改成tab頁，嘿嘿，你喜歡tab頁，我就喜歡下拉框，測試部難到沒有別的事情做了嗎，做這么無聊的事，也就是說，有關操作習慣問題本就是你有你的習慣，我有我的習慣，憑什么就說你的習慣是代表了廣大人民群眾呢？是吧？
看了上面一段，相信大家就知道了什么樣的問題會得到認同，這樣的問題，根本不用你去說服誰，但是，這個世界如果如此簡單，就不會有戰爭了，是吧，所以，我剛才說的只是開發人員的立場，說這些只是讓大家明白一個心理特性，並不意味着，開發人員的這種立場在任何場景都是正確的。
所以，還有一個測試人員的立場問題，對測試而言，我們有各種測試方法去發現bug，有時有的測試方法做出來的測試結果確實發現了問題，但這個問題可能會引發開發人員的反感，這是因為開發人員對測試的工作不了解造成的，比如，我們用邊界測試發現一個問題，但開發人員會說，誰會去輸入這樣的數值呢，在實際工作中，人家是不會這樣操作的，所以拒絕修改這樣的問題，怎么辦呢？這個時候，其實如果一味的讓每個測試人員去與每個開發人員講道理做宣傳，其實效率是低下的，而應該把這一類問題記錄下來，由測試部門進行一個評估，然后與項目負責人進行溝通，在一個適合的時間點（致命問題、嚴重問題都改得差不多且還有時間的時候），對此類問題進行一個全面的修改，如果是一個好的公司與部門，還會就此類問題進行總結歸類，並對此類問題定義出嚴重程度與修改的優先等級，如此就完成了一項過程改進，當下個項目出現類似的問題時，一個制度化的結果已經在這里了，開發人員再次見到類似問題，自己就會在已經把致命與嚴重問題修改完成的情況下，對此種等級的問題再進行修改，而不需要再次做沒有必要的溝通了。再比如使用操作性問題，其實就是一種體驗測試，如果這種問題由每一個測試人員零星提出，不但沒有科學調查與說服力，也會得到開發人員的白眼，所以有關使用方便的問題，也應該單獨的當成一個整體事件去做，而立下科學調查的標准化決議，當項目組與測試部與市場都搭成統一標准后，做這些事，還會有阻力嗎？
我看有的人的解決方法是人情世故，有的人的方法則是權利壓人，還有的人的方法是每回都去以理服人（以德服人，怎么感覺測試總是低聲下氣的？難怪人家不改你的問題），還有總總方法，但不是有后遺症，就是回回都要如此，搞得效率低下，所以真正的方法應該是，把一項不太受到開發人員重視，但又確實是不可小視的那些問題，想辦法通過外交努力，搭成統一的科學的標准化的制度化的行業規范，當一個制度在這里時，沒有人會覺得你是和他過不去，只會覺得，這是制度的要求，我們本就都該這樣做，就好像你遲到了，你不會認為是人事MM對你有偏見，也不會認為人事MM水平低，不懂得以人為本的道理吧？當然不會，因為幾點上班是一項制度。有人見過搞人力資源的人在網上發貼問：請問人事如何更有效的說服員工們不要遲到呢？呵呵，一家之言哈！
至於那些根本就不是問題的問題，求求你們千萬不要用你和開發人員的好關系，把不是問題的問題給修改了（還好有問題審核與軟件配置管理），我的主呀，阿米托佛！
| 我認為，測試人員應該很明確的記錄這個bug，然后查看設計中是否有相關的設計，如果是設計中有而開發人員沒有實現，那么就拿着設計文檔和開發人員談。如果設計中沒有，就看需求中是否有相關內容，如果有就要找項目經理來看，是不是需要在設計中加入這一塊內容。如果需求中都沒有，但是測試人員仍舊認為是一個bug，那么就應該找項目經理談，由項目經理決定是否確認其為bug，是否需要修改。總之，不能夠隨意放過任何一個測試出來的bug，也不能夠和開發人員弄僵關系。我們應該讓他們知道，我們做的一切都是為了項目能夠更好的完成，而且就算我們找來項目經理討論，不是打小報告，而是找來比較權威的人士來做決策。 |