-
Bug多,有沒有修正,沒有修正還能出貨嗎?所以關鍵在有沒有修正Bug..
至於Bug怎麼找來的,我認為應該在測試計畫就要定義「要怎麼找Bug」,而不是找到Bug之後才去研究怎麼找來的。
-
以我個人的經驗,以 Bug 數量作為「軟體品質管理指標」的效果是很差的。一個 newbie programmer 可以在一天內搞出100個 bugs ,又在一天內全部被 senior programmer 修正。但有時一個 senior programmer 也會被一個 bug 困住好幾天。這樣能夠衡量什麼呢?也許更適合作為 programmer 的技術指標吧。
從 PM 的角度來看,以使用者和開發者都認可的 use case 為準,必須在此 use case 的範疇下無 bug 才能交貨。因此開發者關心的應該是開發過程中的 bug 。交貨後才發現的 bug ,確實「為時已晚」。
不過我觀察國內的 case 好像有個現象,使用者不參與 use case 內容的,彷彿使用者跟這軟體沒關係。依據開發者單方面規劃的 use case 來撰寫 test case ,通常驗收時都可以過關,等使用者實際上線後問題百出再來修正。這種現象好像很正常,但我個人總覺得哪裡不對。
-
完全同意。這讓我想起來獨孤木在 Taiwan.CNet 上發表的一篇專案管理文章,當初看到這篇文章時,差點笑翻。這種典型的上班族笑話,沒有親身經歷過的人看不出笑點在哪。
甲方 (使用者) 在看到乙方 (軟體開發廠商) 的雛形之後,往往就會產生先入為主的印象。雛形不好看,甲方就認為這乙方能力不行;雛形太好看,甲方就會對結果產生不切實際的期待。動輒得疚,兩面不是人。
我原本以為塑模工具的使用,可以減少這個問題,甚至可以讓使用者自己塑模。但我的想法在實際進入軟體產業後,被批評「太前衛」,實際上連乙方自己都不用塑模工具,又如何能指望甲方會用?這又牽扯到國內資訊教育的問題了,甲方接口單位通常是甲方的 MIS ,通常跟乙方一樣是資訊科班出身,但依我側面了解 (我不是資訊科班出身的) ,國內資訊教育對「資訊軟體的生產過程」這方面的知識可說是付之闕如,也難怪甲方無法參與開發流程,甚至參與後反而成為專案的阻力。
發表回應
推文( 0 )
看了您的幾篇文章, 對於您的用語以及談到的事情有種莫名的親切感. 是否您曾任職於國內某大防毒軟體廠商呢?