This page looks plain and unstyled because you're using a non-standard compliant browser. To see it in its best form, please visit upgrade to a browser that supports web standards. It's free and painless.

喲哪桑的軟體習作簿 會員登入 會員註冊

« 上一篇 | 下一篇 »

Bug 多,品質好;Bug 少,還是品質好!這是怎麼一回事呢?

因為你少檢查了一些東西,才會推出這樣奇怪的結論!

繼續閱讀 ...

  1. [回覆]

    看了您的幾篇文章, 對於您的用語以及談到的事情有種莫名的親切感. 是否您曾任職於國內某大防毒軟體廠商呢?

    satomi 回應於 23 八月, 2006 11:04

  2. [回覆]

    Bug多,有沒有修正,沒有修正還能出貨嗎?所以關鍵在有沒有修正Bug..
    至於Bug怎麼找來的,我認為應該在測試計畫就要定義「要怎麼找Bug」,而不是找到Bug之後才去研究怎麼找來的。

    法蘭克 回應於 28 八月, 2006 09:47

      計畫很重要,但是… [回覆]

      謝謝法蘭克大大!您提到一個很重要的東西︰我們應透過測試計畫,來決定我們「應該」如何來找 bug。

      計畫當然很重要。但是,很多計畫都執行的不好。這種例子太多了,我們大有為的政府就是個好例子……

      因此,我會拿實際執行結果與測試計畫相比,做為我初評「測試是否完善」的根據之一,看看我們是否能夠「說到並做到」。若執行跟不上計畫,那就不太妙了。

      還有其他方法來看看測試是否完善,好比 code coverage 也很常見。

      先拋磚引玉,謝謝法蘭克,更有請其他大師來補充!

      喲哪桑 回應於 28 八月, 2006 14:18

  3. [回覆]

    以我個人的經驗,以 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 ,通常驗收時都可以過關,等使用者實際上線後問題百出再來修正。這種現象好像很正常,但我個人總覺得哪裡不對。

    遊手好閒的石頭成 回應於 23 九月, 2006 00:21

      Echo你一下 [回覆]

      的確, 在PSP(Personal Software Process)裡, 每個工程師的defect rate, 是工程師衡量自己的指標之一.

      聽到這裡, 很多人立刻會跳腳:
      怎麼可以這樣做?
      這樣還有誰敢寫code?

      不過, bug本就是人寫出來的, 再厲害的投手也不可能永遠不失分, 但還是要衡量自己, 才知自己好不好, 以求技藝的進步.

      至於你最後的疑惑, 其實, use case 本就是user's case, 沒有 user, 真的很怪, 卻是事實. 曾聽某位PMP界的大老說, 在台灣, 甲方的問題, 比乙方大的多, 但是大家都在改進乙方, 甲方沒在改進. 你覺得呢?

      喲哪桑 回應於 27 九月, 2006 18:35

  4. [回覆]

    完全同意。這讓我想起來獨孤木在 Taiwan.CNet 上發表的一篇專案管理文章,當初看到這篇文章時,差點笑翻。這種典型的上班族笑話,沒有親身經歷過的人看不出笑點在哪。

    甲方 (使用者) 在看到乙方 (軟體開發廠商) 的雛形之後,往往就會產生先入為主的印象。雛形不好看,甲方就認為這乙方能力不行;雛形太好看,甲方就會對結果產生不切實際的期待。動輒得疚,兩面不是人。

    我原本以為塑模工具的使用,可以減少這個問題,甚至可以讓使用者自己塑模。但我的想法在實際進入軟體產業後,被批評「太前衛」,實際上連乙方自己都不用塑模工具,又如何能指望甲方會用?這又牽扯到國內資訊教育的問題了,甲方接口單位通常是甲方的 MIS ,通常跟乙方一樣是資訊科班出身,但依我側面了解 (我不是資訊科班出身的) ,國內資訊教育對「資訊軟體的生產過程」這方面的知識可說是付之闕如,也難怪甲方無法參與開發流程,甚至參與後反而成為專案的阻力。

    遊手好閒的石頭成 回應於 28 九月, 2006 01:45

  5. Re: 那些 Bug 是怎麼找來的? [回覆]
    wszxy 回應於 03 八月, 2010 12:01

發表回應

 暱稱 (必填)

 標題

 個人網頁

 電子郵件

authimage 
 認證碼 (必填)