在軟件開發中都會有開發人員（以下簡稱開發）和測試人員（以下簡稱測試），在一些小型公司可能並沒有測試，僅僅是開發兼任測試。在這裡我僅針對於有專業的測試和專業的開發的項目。
每個公司應該都有考核機制，對於開發和測試的考核實際上很難量化，通常來講大的方向就是開發所負責模塊的bug數，對於測試來講就是測出來的bug數，但這真的有效嗎？這也許對開發有約束力，理論上開發是能夠自己控制bug數的，如果從產生的bug數來評判開發的績效還算有效，這樣開發自然就會把代碼寫得更加認真。但如果根據測試測出來的bug數來評判測試的績效，就假設測試為了自己的績效瞎測怎麼預防？
單純地根據bug數來評判開發和測試的績效，我認為顯然不合適。這會導致開發寫代碼時小心翼翼沒問題，但測試就可能會不可避免的測一些莫名其妙的bug，bug多了測試的績效高了，同時開發的績效不就低了麼？當然實際當中顯然也不會根據這一個維度來評判績效。
很多時候開發和測試的關係僅是零和博弈。
開發和測試存在目的是什麼？開發是為了實現客戶的需求，測試是為了保證軟件的質量。兩者應該是合作共贏的關係，不是零和博弈，不是此消彼長，不是你勝我敗。開發和測試實際上是很矛盾的，兩者既對立又統一。
毫無疑問開發和測試應該是對立的，如果因為開發過多幹涉測試的工作，那這個工作根本無法開展，軟件質量根本無法保障，測試崗位的設立毫無意義。兩者不存在上下級關係，開發應不懼怕測試測出來的bug，同時測試應“多”測出bug，這個“多”並不是數量上的多，而是質量上的多。開發的代碼有質量之說，我想說的是bug的質量也是一個測試水平的體現。開發不能把測試當做大爺一樣來對待，測試更不能把自己擺在大爺的位置。
開發和測試的關係同樣也是統一的。我認為測試的職責或者測試的成就感不是來自於測出bug，而是能協助開發找出問題並且定位問題。這裡的協助並無主次的關係，對於出現bug地方的代碼實現測試也許不懂，開發也許也懶得聽測試的意見，這個時候並不是測試要和開發一起去尋找代碼實現上的問題，而是和開發一起梳理功能的邏輯有無問題，測試以測試的經驗和專業技能協助開發。兩者統一關係的體現在這個軟件是共同的結晶，並不是開發一方的成果，目的都是為了軟件能更快更好的發佈。
我想在計算機類的專業裡，開發和測試兩個方向就類似高中時期的理科和文科。很大部分在高中數學不行或者成績不行就選擇文科認為簡單，計算機類的專業裡稍微有點“志氣”的學生也會選擇做開發而不會選擇做測試，測試的標籤就是簡單 ，當然這個現象和類比也許並不準確。
測試人員在測試的時候應有一定的專業素養，測試不能毫無邏輯，毫無規劃的一通亂測，這有個好聽的名字——探索性測試。舉個例子：
測試：“出問題啦！某某某快來看啊！”
開發：“怎麼操作的？”
測試：“我就點了哪兒就出現這個了啊。”
開發：“那等等，我看下後臺日誌，你再操作一下。”
測試：“怎麼不能復現了啊，剛剛我就是這麼點的啊。”
開發：“……”
這個場景常見，如果這個bug本身就是偶現的bug那還說得過去。如果問測試怎麼操作的，測試一臉懵逼的說：“我不知道，我忘了。但是你這個有問題就是bug。”這得多花多少開發的時間去排查這個問題啊，不是不讓你測，是讓你有套路有思路的測，這是對於測試自身素養問題。
同樣對於開發人員也是一樣的，自測是一個很好的習慣，拋開開發的代碼能力，這是對於開發人員最基本的素養。舉個例子：
開發內心：“終於做完這個功能了，不測了，反正有測試，讓他們去測，測出問題再改。”
很大部分的bug是因為開發自身沒有做好自測，單元測試並不是在每個公司每個項目每個模塊都有，甚至很多開發人員幾年工作經驗也不知道怎麼編寫單元測試。認為自己的工作就是寫代碼，檢驗功能是否完善是否有bug的工作應該交給測試去做。
對於開發和測試素養的問題我想這是在理想狀態下，或者只存在理論上。實際上開發測試魚龍混雜、參差不齊、濫竽充數都有可能。但對於開發和測試關係萬萬不可將開發和測試放在對立面，同樣應考慮他們是統一的，矛與盾缺一不可，合作共贏而不是零和博弈。如何維繫兩者的關係也是一個很值得研究的問題。