如何寫好測試報告(2)

　　回復：如何寫好測試報告 曾盛開(技術部)

　　我看完了，總是覺得程序員和測試員之間在問題分歧上存在很多不同之處，其中包括個人專業知識的深度，對軟件理解的能力，對業務、程序的理解能力，產品開發成本、周期與bug之間的協調。

　　諸多方面加起來，使我的脾氣在溝通協調bug問題上變得很容易激昂，或者說發火，頭腦發熱。程序員多少都有些自大，不甘屈服的情緒，而且確實很多東西由于變得和以前寫好、定好的需求有出入，導致做好的東西可能又被推翻。。。心里那種滋味很不好受的。。。畢竟每個地方和環節都是自己努力去想過的，有時候一個問題可能是花去幾天時間確保那樣做沒有漏洞和正確。

　　我感覺到兩個部門之間協調缺少更多互動，比如產品部在測試之前或者有空時候可以培訓一下技術部，一般會測試哪些東西，如何測試的，這樣子程序員心里多少有更多的底，在寫程序的時候會有一種警惕性，從而產品部也會輕松一些，雙方有利，應該是三方有利，公司最有利。。產品部也要考慮如何幫助程序員快速有利地處理bug，而不是一味為了bug而找bug，這根本背離了兩個部門合作的基調;技術部也同樣有責任去幫助產品部理解好系統運行的流程，找出隱藏的bug 。

　　另外，我想說的是在文檔細節上面不要過分苛求，否則一方面是開發進度和成本，另一方面是使Xp輕量級文檔開發流程又變成重量級文檔開發，程序員為了文檔忙于疲命。。我深有體會的，文檔花去的時間幾乎占用了1/4-1/3。

　　我覺得在測試的同事面前談測試，有些班門弄斧，關公賣刀，但有些話不得不說，那就開誠布公拿出來，就算貽笑大方也好吧~~~

　　回復：回復：如何寫好測試報告 李鵬

　　文檔花去的時間幾乎占用了1/4-1/3：這個時間我不覺得多，我覺得不夠?；ㄔ谛枨蠖x，開發文檔方面的時間應該是1/2以上

　　我覺得XP編程不適合我們，理由有三：

　　1、我們的8.0項目跨度有近2年，可以說是個中型項目，xp編程比較適合小項目(2-3個月)。

　　2、xp編程理論中基本上沒有提到如何對程序進行系統的測試，而我們公司非常重視軟件測試，程序員和測試員的比例近1：1。

　　3、xp中對文檔的定義是“夠用就好”，而在眾多的工程理論(rup、cmm)中都建議要有詳盡得需求和開發文檔?；ㄔ谛枨蠖x，開發文檔方面的時間應該是1/2以上。

　　回復：回復：如何寫好測試報告 黃為東

　　技術部和產品部的斗爭性，有它的積極作用，但確實存在兩個部門目標不一致性的問題，既存在內部損耗，又存在被共同忽視的中間地帶。

　　大膽設想一下，假設把技術部和產品部合并為一個大部，每個小組都配2個測試員，是否會更好呢?這樣測試人員對本組開發人員的配合密切程度也許會更高。問題是，測試的專業性、分工性是否會下降?

　　該怎么組織，是一個大問題。

　　回復：回復：如何寫好測試報告 蒲冬梅

　　產品只有足夠人性化，用戶才會樂意使用此功能，而不是買回去就將其束之高閣。文檔只有足夠詳細化，才能為產品部測試提供準確的依據。因此就需要產品部與技術部能夠有更多溝通，更充分的文檔準備，更大的耐心。

　　因為最終目標我們只有一個，做出來的產品要對得起用戶。因此我們需要彼此體諒，理解與尊重。

　　如果技術部有時間或是計劃能夠安排接受產品部的測試培訓，我想我們部門每個同事都會舉雙手雙腳贊成的。這樣應該能減少很大部份測試的工作量。

　　關于為了找BUG而找BUG的說法，我覺得是很有必要就此申明一兩句的?，F在產品部最終提交到技術部的BUG都是有人負責審核的(BUG的定位是否準確，BUG的描述是否清晰等)。由于BUG的數量，這項工作其實是相當費時與費力的，因此曾停過一段的時間，但是為了提高BUG的質量和減少為了BUG而需要與產品部溝通的時間，這部份工作我們依然堅持在做。但是難免會有部份BUG在產品部進行準確定位是很困難的，而如果改為由技術部來定位則僅僅只是幾分鐘的事情，因此我們并未嚴格控制每個BUG都會精確定位，但是我們的目標是盡可能減少技術部為了BUG的描述或定位而進行多次反復的溝通。

　　因此就BUG本身的問題，也歡迎技術部能多多提意見，我們一定堅絕改正。

原文轉自：http://www.uml.org.cn/Test/200512212.htm