通常大家發現軟件缺陷時會對軟件缺陷進行分類，可分類的方式只有一種，就是嚴重極別,難道沒有其它的分法嗎。比如我們碰到下面這種情況，測試人員發現有一種功能是必需加入進去的，這時他與程序員說，程序員說沒有時間或是不必要，這時這種情況則會形成兩者的扯皮，最終的結果也就不了了知了，這樣會戳傷了測試人員的積極性，下次他們再也不會盡心的考慮產品的問題，只要可以運行就可以了。其實這種情況是可以解決的,下面我會提到一個新的軟件缺陷分類概念，從而有效的解決這個問題。
在軟件缺陷中不僅僅只是嚴重極別，更多的則是功能沒有做到。說到這裏也許大家都理解了，就是需求沒有考慮到，可需求不會一次就很完美的，需要大家的共同努力，來不斷的完善。那麼怎樣才能讓測試人員提出的好的建議得到有效的執行？這就是我下面想說的。在軟件缺陷中還有一種分法，跟據缺陷內容來分，主要分爲需求Bug與程序Bug，對於這種分法的好處就是明確了Bug處理的責任人。對於程序Bug我們都知道是由相關開發人員進行處理。下面主要討論一下需求Bug,需求Bug從名稱上來就知道是要交由需求人員進行處理，可怎麼處理，怎樣在處理的過程中有效的讓這些創意得到體現。現在我們都有Bug管理系統，這時我們的測試人員將需求Bug不是提交給程序員，而是提交給需求分析人員，由他們進行處理，不過這裏我想強調的是對需求Bug的定位，如果這個Bug在軟件需求說明書中明確提到了，這時就不可能定位它爲需求Bug，它是必需讓程序員實現的，稱爲軟件功能缺陷，提交由程序員進行處理。但如果需求說明書沒有明確提到的，我們則可以定位爲需求Bug，處理的流程如圖。
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
<?xml:namespace prefix = w ns = "urn:schemas-microsoft-com:office:word" />
圖1
這樣處理有以下好處，首先需求Bug再不象以前，沒有人進行確認，需求的處理人員本來就是需求人員，由他們確認與跟蹤是最好不過的，因爲他們對需求有絕對的權威。同時測試人員其實就是最早的用戶，他們的需求就是用戶的需求，這種方法加強了需求人員與測試人員的溝通，使需求得到有效的補充，從而讓產品更加完善。還有測試人員從本質上來說與程序員還是對立的，這裏如果爲了這樣一個不是軟件本身問題的問題形成與開發人員的對立，則會出現贏得戰役而丟失整個戰爭的情況，測試人員協調好與開發人員的關係，讓他們更有效的對軟件本身的缺陷形成有效的關注是最好的。還有最爲關鍵的一點，測試人員的激情是最重要的，如果他們的想法沒有得到體現，這時會漸漸的失去對測試的興趣，從而軟件的質量則會無法得到保證，通過這種方法可以讓他們看到自己的建議可以通過對需求人員的反映得到實現，讓他們時時覺得自己的想法是可以通過這種方法來有效的推行，這樣工作的積極性纔會有保障。
不過從實施的角度來說，還是有一定的困難的，首先要讓大家改變以前那種凡是Bug就是由開發人員負責的觀念，其次需求人員的工作量是要加大的，不過廣泛的瞭解需求是他們的本份工作，想來不會很困難，還有必需要有有效的Bug管理工具，比如BugManage等等，不要出現那種對需求人員說了，可過兩天就忘的情況出現，這時需求Bug的生命週期會出現跨越兩個軟件開發週期，因爲有些需求會在下一版實現，這時測試人員需要延長對這些需求Bug的管理，不過我想這些需求是他們提出的，會有興趣對這些Bug進行管理的。
陳衛俊
9/9/2003