自從我幹上軟體開發這一行，並且使用了bug跟蹤系統，我們在每乙個專案裡都會糾結乙個基本的問題：你怎麼能把bug與功能需求區分開來？
當然，如果程式崩潰了，這毫無疑問是bug。不過，那也許只佔你每天所處理問題的10%。為了避免專案的徹底失敗，真正的殺手級bug——有它存在就不能發版的bug——會很快被消滅。而在bug跟蹤系統裡留下來的絕大部分bug，就落入了沒人管的灰色地帶。使用者報告的是bug嗎？不完全是。使用者在要求乙個新功能或完善某個既有功能嗎？也不完全是。好吧，那到底是什麼？
這是乙個令人犯難的問題。進一步說，我認為大部分bug跟蹤系統都在「坑」我們，因為它們讓我們非要回答這種無聊問題，逼著我們站隊——要麼海菲茨，要麼麥考伊斯；要麼可口可樂，要麼百事可樂；要麼是bug，要麼是功能需求——這是乙個痛苦的抉擇，選擇哪一方均在一念之差，因為大部分時候兩者皆可。從使用者的角度看，bug和功能需求是沒有區別的。如果你想用乙個軟體（或者**）做某件事情，但因為某個功能沒有實現而無法完成；相比於你在使用過程中因為出錯而不得不停下來，兩者之間有區別嗎？
譯者注：美劇《hatfields & mccoys》，又名《血仇》，聚焦於美國聲名狼藉的兩個家族（hatfields和mccoys）之爭。兩大家族的爭執源自於美國南北戰爭時期，anse hatfield和randall mccoy本是要好的哥們兒，但不想後來生變，二人結下仇怨，甚至引得維吉尼亞州和肯塔基州都不安寧。由此，這兩大家族聯手製造了美國史上最臭名昭著的血腥爭端。
我們來看乙個例子：在開發windows應用程式的時候，visual studio沒有使用正確的字型。這算是乙個bug還是功能需求呢？
我個人覺得這是乙個bug。我猜微軟也是這麼認為的（至少理論上是這樣），因為那個問題已經在microsoft connect系統裡存在了4年多。當你開發乙個windows應用程式，除非你刻意想要使用一種特殊字型，你難道不希望使用作業系統的預設字型嗎？好吧，如果你在visual studio 2008裡建立乙個新的窗體，然後新增乙個標籤控制項，看看會是什麼情況吧：
彷彿一下子回到了2023年，因為你看到的是「可愛的」ms sans serif字型。那是所有新窗體的預設字型。你也別見怪了，所有新開發的應用程式看起來都醜陋無比——我的措辭已經很克制了！
下面是乙個對比：一行標籤用了預設字型，另一行標籤顯式設定了預設的gui字型。
縱觀我所使用過的應用軟體，我發現，大部分windows程式設計師根本不關心設計。這可不妙！甚至更糟糕的是，這種對設計的漠視被visual studio攜帶，從2023年開始不斷地感染著每一位使用者。
當然，設計方面的問題是很主觀的。在windows圖形使用者介面的字型使用方面，要是我們能有一些參考資料，那該多好啊！某種類似於標準的東西。就比如微軟給windows vista使用者體驗定義的那些規範：
這樣的規範總共有12條。不過，我想要找的恰恰就是第一條：應用程式應該使用系統字型。
我為windows vista的整體質量扼腕嘆息，為此我也寫過滿滿的一篇文章。上述這份清單看起來很歡樂，其實已經不言而喻。特別是第12條：預留時間提公升「整體質量」，讓我不禁大笑。在開發windows vista的時候，微軟想必對這條規範耿耿於懷。值得注意的是，這些都出自於乙個熱愛vista的傢伙。
對不起，我跑題了。
儘管visual studio 2008裡的視窗字型行為違背了微軟自家的設計規範（中的第一條），這個「bug」卻4年多來一直沒有被修正。它被悄悄地歸類為「功能需求」，然後被束之高閣了。畢竟，沒什麼惡劣影響——使用錯誤的字型不會讓程式崩潰或降低生產力。另一方面，想象一下，自從微軟踐踏自家的設計規範以來，有多少大公司的應用軟體已經被開發出來了啊。要麼因為開發人員沒有意識到應用程式的字型與作業系統不匹配的問題，要麼他們沒時間寫一些必要的權變**來加以糾正。
沒錯，這是乙個小問題。我相信，修正這個問題不會讓visual studio更好賣，比如多賣給大公司幾千個使用授權。這也是它沒人管的原因吧。
問題依舊：這是乙個bug，還是功能需求？
我很喜歡用uservoice（stack overflow採用的就是這個工具），它最讓我心動的一點是，它故意模糊了bug與功能需求之間的界線。不管怎麼說，使用者搞不明白它們之間的區別；更糟糕的是，程式設計師可能會據以搪塞使用者。他們把不想做的事情歸類為「功能需求」，從此以後就置之不理了。他們會據理力爭，嚷嚷著說某個被報告為「bug」的問題顯然不是bug，自然也就不必修復了。罷了吧，別再區分bug和功能需求了，讓它們都見鬼去吧！
我希望，我們全行業都能少花點時間在概念的口舌之爭上，別再煞費苦心地把使用者反饋區分成「bug」或是「功能需求」。面對使用者反饋，我們應該多花點時間做一些有建設性的事情。
那不是Bug，是新需求
自從我幹上軟體開發這一行。而且使用了bug跟蹤系統。我們在每個專案裡都會糾結乙個主要的問題 你怎麼能把bug與功能需求區分開來？當然，假設程式崩潰了，這毫無疑問是bug。只是，那或許僅僅佔你每天所處理問題的10 為了避免專案的徹底失敗。真正的殺手級bug 有它存在就不能發版的bug 會非常快被消滅。...
軟體測試是找BUG，不是找茬
做測試久了，經常會有一些感悟，最近在51上看到一貼，說出了我的心聲，把我一直想寫卻一直以時間為藉口為由拖著未寫的心聲寫出來，摘抄了部分過不，一起紀念測試的年代，測試的心聲。測試好象一直會被一些人誤解 測試就是找茬！經常被問到 你是做什麼的？回答 測試 時，別人馬上反問 你會不會編軟體呀？我說 不會，...
軟體測試是找bug，不是找茬
最近跟乙個朋友聊天，問 你會不會編軟體呀？我說 不會，我是做測試的，不是做開發的！他問 你是專門挑毛病的，是吧？我只是笑著搖搖頭，說 我做測試，是找缺陷，不是找茬！突然對做測試有些想法 第一 測試是找bug，不是找茬。以前在外包做測試，面對的之間人是pm，面對所謂的客戶是開發軟體的人，而且因為離開發...