把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. 把更高層的人拉進來；不少時候都是公說公有理婆說婆有理，這時候就須要一些第三方的同事來幫忙，這我的一般要是能說事的才行，例如研發總監或者項目經理，可是主要不要讓人以爲狐假虎威的感受，這招不適宜常常用。google
男孩子 says:[正規的公司作法:]編碼
感受之因此提出這個問題，是由於公司的體制根本就不完善。
測試人員的職責是測試，研發人員的職責是研發，測試人員提bug，研發人員改bug，誰賦予了測試人員去督促研發人員修改bug的權利了？測試人員又有什麼義務去督促研發人員修改bug呢？
以前跟一個在NEC工做的哥們聊過，在他們單位，測試人員是不直接跟研發人員打交道的。測試和研發中間有個中間角色，咱們暫稱其爲bridge。測試人員的bug提交給bridge，bridge鑑定其是否爲bug，是bug，流轉給研發，不是bug，駁回給測試。一樣道理，研發人員若是reject，也是由bridge與其交流。固然，bridge不是隨便抓我的就能夠當，級別得至關於「技術總監」吧。
固然，目前接觸的好多單位都把這個角色省掉了。一個產品或者項目的測試可能總共也就2-3我的，怎麼捨得派這麼個大牛給你們呢？因此題目描述的問題又是一個不得不面對的事實。
從個人經驗來看，出現這樣的狀況一般不是一些重要的bug，因此測試人員應該儘可能將本身的bug描述的細緻清晰，而後將bug轉交給項目leader處理或者留在評審會時討論，而不該該跟研發人員在這個問題上作過多的爭論，這樣一來耗費時間，而來會影響在後續工做中的合做。
研發人員由於在開發技術上的優點，經常會對測試存在必定偏見，測試人員應該可以認識並理解這一點。spa
樂遊 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，咱們能夠從下面幾個方面來考慮：
1、爲何定爲BUG
- BUG描述------測試員在提出BUG時，要注意對BUG進行必要的描述，例：BUG出現的環境、出現該BUG進行的操做、預期結果和實際結果、BUG出現的概率，若是使用的BUG管理工具的容許，能夠對該BUG添加一些附件：截圖、腳本等，Jira、Lotus好像均可以添加附件。一方面增長開發對BUG的閱讀、定位，另外一方面能經過有利的論據證實該問題是BUG
- BUG復現------提交BUG後要保證BUG復現，這樣在項目經理、測試經理、開發人員爭論BUG時，能強有力的證實該BUG是存在的。
- BUG依據-------理論上，產品中不知足用戶提出的需求就能夠定爲BUG，這也是測試前期進行需求評審的緣由。可是，目前不少公司的軟件項目對其中的細節描述很不具體，致使了開發與測試關於BUG的歧義。在定BUG的時候咱們能夠本着這樣一個原則：和當今流行產品作對比，好比說公司在作個搜索引擎，開發將搜索引擎的位置放在頁面的底部，咱們就能夠說這是一個BUG。理由很簡單，百度、google的搜索框都在頁面的上部。
2、測試經理對BUG的認同
- 測試經理的經驗-----測試經理通常來講都是工做幾年，有至關豐富的項目經驗，我公司測試人員提出的BUG，一線的測試經理都要審覈，審覈經過才轉到項目經理，這樣避免了因爲測試員工做經驗不足和我的主觀意願致使BUG錯誤認定的狀況。
- 測試經理的信賴-----測試經理對BUG認同後，也就說明了該問題是BUG，在後續的爭論中不會出現測試經理搪塞的狀況，對測試人員也是很是有利的。
3、有效的溝通
- "犧牲色相"-----該方法要求測試人員爲了工做，主動和開發創建良好的關係。譬如：請開發吃飯等等，這種方法最有效，也是百試百靈。但我的不建議這麼作，工做就工做，耍手段是很差滴。
- "良好的同事關係"----這種方法要求測試和開發平等的地位，測試要本着"個人工做職責就是讓軟件運行的更好"，經過合理的溝通手段，讓開發能認同本身的觀點，並進行BUG的修復。不要由於本身對技術瞭解不如開發深，就不敢提問題。
- "強調BUG的影響"----溝通中提出修改BUG帶來的好處，不修改BUG將要致使的問題，讓開發明白問題的嚴重性。那怕是用戶體驗的BUG，也能夠藉助用戶的場景，說明修復BUG的必要性
4、利用身邊的資源
- 上級領導-----藉助測試經理和項目經理，有時候我的不能協調解決的問題，就不要逞強，讓測試經理和項目經理來協調，切忌不要悄悄的在項目經理面前說開發的壞處，你們都是打工的何須呢，何況不必定能起到做用。要記住--本身找項目經理和測試經理是協議矛盾的，解決問題的。
- 部門例會-----不少公司，每週或每個月都會進行部門例會，方便各個部門間交流溝通，能夠由測試經理反映下最近測試狀況，測試員發現多少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，也不可以和開發人員弄僵關係。咱們應該讓他們知道，咱們作的一切都是爲了項目可以更好的完成，並且就算咱們找來項目經理討論，不是打小報告，而是找來比較權威的人士來作決策。
最後
歡迎關注公衆號：測試人追風，領取一線大廠Python自動化面試題總結+各知識點學習思惟導+一份100頁pdf文檔的軟件測試開發核心知識點總結！