是Bug? 還是Feature?


喲哪桑在他blog中, 有post 一篇文章 "Feature Request, Or Bug Fixing?"
http://jonathanspeaking.blogspot.com/2008/10/feature-request-or-bug-fixing.html

其中談到一個長久以來爭辯不休的問題: 當你找到一個問題, 你會視為bug, 還是視為feature? 當喲哪桑一發表完後, 已起很大的迴響, 很多人提出不同的看法. 我想是很值得大家去看看

最近小弟在閑逛時, 剛有看到相關的blog文, 因此找出來讓大家參考一下另一種說法.
Bug v.s. Feature
http://blog.abakas.com/2008/10/bug-vs-feature.html

當QA找到一個"bug" 時, 有時候很容易引起以下的討論

"well, it SHOULD do this, so of course it's a bug and we need to fix it really fast"
或是
"we didn't screw up and this is something new to us so it's a new feature"

尤其是再你有一大堆bug要處理的時候, 人們的心態就會非常的defensive, 會根據對他最有利的結果, 加以反駁或是防禦.

作者認為不管他是什麼都不重要.
因為二者都需要被排被處理的優先順序, 要被追蹤, 執行, 測試, 然後最後release 它.

然而, 為了避免大家爭吵不休, 作者有個簡單的判斷法則:

If it's something we've never tried to do before, then it's a feature.
If it's something we've tried to do and have messed up or missed an edge case, then it's a bug.

作者認為, 雖然它並不是很完美, 並且有些地方有點模糊, 但至少還算明確
你認為這個rule有用嗎?

另外一個在喲哪桑的文章中提到: "既然問題已經存在一兩年又沒有人解，表示這問題也不是挺重要"

老實說, 我也是無敵感冒的, 因為個人認為他是一個推託的用詞. 只是當你在忙的時候, 自然就會不自覺慣用這樣的伎倆.

其實不管他是否真的沒發現, 那都不重要. 重要的是你是否想處理. 若是想處理, 你就會評估可能性及所需resource, 若是允許你便會加你的work item, 去tracking它. 而不是一開頭就拿這句話來搪塞.

不過, 講了半天, 我也承認人性是很難克服的. 包括我自己, 在壓力大的狀況下, 很容易挑一條容易走的路, 而不一定是正確的路來走....... 所以, 也無法太則怪別人.




kojenchieh 發表在 痞客邦 留言(0) 人氣()

▲top
Unit Testing的價值被過度高估

Testing is overrated
http://railspikes.com/2008/7/11/testing-is-overrated
Posted by Luke Francl
on Friday, July 11

作者在這篇文章中, 提到了一個觀點: "測試的價值被過度高估". 因為在agile中, 強調RD要做unit testing, 要採用TDD. 但是作者認為這樣是不夠的, 他認為這個效果有過度被渲染, 事實上RD還是花很多時間在做debugging. 所以根據Steve McConnell (Code Complete一書的作者)所說的, 必須還要搭配各式不同的方法,來確保軟體的品質, 因為每種方法所找出的bug是不同的.


1. RD測試所帶來的問題
首先, 作者先談為何光是RD做unit testing是不夠的. 由RD來做測試會有一些limitations, 這些是作者所觀察到的

A. 測試是非常困難的....大部分的RD並不十分擅長
- Programmers tend write “clean” tests that verify the code works, not “dirty” tests that test error conditions.
- Steve McConnell reports, “Immature testing organizations tend to have about five clean tests for every dirty test.
- Mature testing organizations tend to have five dirty tests for every clean test.
- This ratio is not reversed by reducing the clean tests; it’s done by creating 25 times as many dirty tests.” (Code Complete 2, p. 504)

B. 你沒有辦法測試尚未寫出的Code
- Robert L. Glass discusses this several times in his book Facts and Fallacies of Software Engineering.
- Missing requirements are the hardest errors to correct, because often times only the customer can detect them.
- Unit tests with total code coverage (and even code inspections) can easily fail to detect missing code.
- Therefore, these errors can slip into production (or your iteration release).
- Tests alone won’t solve this problem, but I have found that writing tests is often a good way to suss out missing requirements.

C. Test Cases也可能包含錯誤
- Numerous studies have found that test cases are as likely to have errors as the code they’re testing (see Code Complete 2, p. 522).
- So who tests the tests? Only review of the tests can find deficiencies in the tests themselves.

D. RD所做的測試並不能有效地找出Bugs
- To cap it all off, developer testing isn’t all that effective at finding defects.
- Defect-Detection Rates of Selected Techniques (Code Complete 2, p. 470)
Removal Step                         Lowest Rate     Modal Rate     Highest Rate
Informal design reviews         25%                 35%             40%
Formal design inspections     45%                 55%             65%
Informal code reviews             20%                 25%             35%
Modeling or prototyping         35%                 65%             80%
Formal code inspections         45%                 60%             70%
Unit test                                 15%                 30%             50%
System test                             25%                 40%             55%



2. 不要把所有雞蛋放在同一個籃子
因此作者提出不要把所有雞蛋放在同一個籃子的論調. 不同種類的defect detection 技巧, 能找到不同種類的問題. 因此你不能只是用其中一種, unit testing, manual testing, usability testing 和 code review 都要使用

A. Manual testing
- As mentioned above, programmers tend to test the “clean” path through their code.
- A human tester can quickly make mincemeat of the developer’s fairy world.
- Good QA testers are worth their weight in gold.
- I once worked with a guy who was incredibly skilled at finding the most obscure bugs.
- He could describe exactly how to replicate the problem, and he would dig into the log files for a better error report, and to get an indication of the location of the defect.
- Joel Spolsky wrote a great article on the Top Five (Wrong) Reasons You Don’t Have Testers—and why you shouldn’t put developers on this task. We’re just not that good at it.
http://www.joelonsoftware.com/articles/fog0000000067.html

B. Code reviews
- Code reviews and formal code inspections are incredibly effective at finding defects (studies show they are more effective at finding defects than developer testing, and cheaper too), and the peer pressure of knowing your code will be scrutinized helps ensure higher quality right off the bat.
- I still remember my first code review. I was doing the ArsDigita Boot Camp which was a 2-week course on building web applications.
- At the end of the first week, we had to walk through our code in front of the group and face questions from the instructor.
- It was incredibly nerve-wracking! But I worked hard to make the code as good as I could.
- This stresses the importance of what Robert L. Glass calls the “sociological aspects” of peer review.
- Reviewing code is a delicate activity. Remember to review the code…not the author.

C. Usability tests
- Another huge problem with developer tests is that they won’t tell you if your software sucks.
- You can have 1500% test coverage and no known defects and your software can still be an unusable mess.
- Jeff Atwood calls this the ultimate unit test failure:

    I often get frustrated with the depth of our obsession over things like code coverage. Unit testing and code coverage are good things. But perfectly executed code coverage doesn’t mean users will use your program. Or that it’s even worth using in the first place. When users can’t figure out how to use your app, when users pass over your app in favor of something easier or simpler to use, that’s the ultimate unit test failure. That’s the problem you should be trying to solve.
    (這段話, 道出了coverage test的弱點. coverage高並不代表你程式quality高, 可能是你程式沒有做太多error handling, 或是有些需求沒有寫到, 甚至也可能是你用的criteria太低[譬如你只用function coverage or statement coverage來看結果 ])
    
- Fortunately, usability tests are easy and cheap to run.  (這點個人是有點持保留態度, 但也可能我不知usability test如何執行. 各位先進, 還請分享一下)
- Don’t Make Me Think is your Bible here (the chapters about usability testing are available online).
- For Tumblon, we’ve been conducting usability tests with screen recording software that costs $20.
- The problems we’ve found with usability tests have been amazing. It punctures your ego, while at the same time giving you the motivation to fix the problems.



那為什麼Unit Testing有用呢?

作者認為Unit testing 之所以有用, 是因為它讓我們思考我們所寫的code是否有問題, 是否有可以改進的地方.

作者還引用的Michael Feathers所寫的文章:The Flawed Theory Behind Unit Testing, 來佐證
http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html

    One very common theory about unit testing is that quality comes from removing the errors that your tests catch. Superficially, this makes sense….It’s a nice theory, but it’s wrong….

    In the software industry, we’ve been chasing quality for years. The interesting thing is there are a number of things that work. Design by Contract works. Test Driven Development works. So do Clean Room, code inspections and the use of higher-level languages.

    All of these techniques have been shown to increase quality. And, if we look closely we can see why: all of them force us to reflect on our code.

    That’s the magic, and it’s why unit testing works also. When you write unit tests, TDD-style or after your development, you scrutinize, you think, and often you prevent problems without even encountering a test failure.

So: adapt practices that make you think about your code; and supplement them with other defect detection techniques.

所以千萬不要是為了做事而做事, 而是要思考你做這事能幫助你什麼, 你為什麼要做這件事



 既然Unit Testing是不夠的, 那我們為什麼還要RD只做這些事情呢?

做這認為可能的理由如下:
Most programmers can’t hire a QA person or conduct even a $50 usability test.
And perhaps most places don’t have a culture of code reviews.
But they can write tests. Unit tests! Specs! Mocks! Stubs! Integration tests! Fuzz tests!
也就是說這些事情是他們所能控制的, 所以他們只好一直做這些事情.

這聽起來是不是很諷刺, 可是這也是我們平時容易做的事: 只做容易做的, 或是能做的. 但不是做正確的, 或是重要的.

最後作者再次強調:
No single technique is effective at detecting all defects.
We need manual testing, peer reviews, usability testing and developer testing (and that’s just the start) if we want to produce high-quality software.


Resources
* Robert L. Glass, Facts and Fallacies of Software Engineering.
* Steve McConnell, Code Complete 2nd ed, Chapters 20-22.
* Steve Krug, Don’t Make Me Think.


kojenchieh 發表在 痞客邦 留言(0) 人氣()

▲top
什麼叫做"Code Complete"?

"Done" Is So Fuzzy
http://blog.abakas.com/2008/05/done-is-so-fuzzy.html


每次有engineers說他已經code complete了, 我都會很困惑. 因為甚麼是code complete, 你我之間的定義是很不一致的. Code complete是一個很模糊的的term, 因此常常就是出現意想不到的結果.

這裡是作者整理出, 他所知的code complete的可能狀況:

1. Feature Complete.
2. Feature Complete With Tests.
3. Feature Complete With Passing Tests.
4. Demo-able.
5. Release-able.
6. Perfect.

作者提到, 重點不在於有這麼多不同的定義, 而是在於你們是否有一致定義. 如果沒有, 那才是大問題

在公司內部, 我還有聽到另一種做法
Step 1. Feature Complete  --> 達到50% code complete
Step 2. Feature Complete with Code Review  --> 達到80% code complete
Step 3. Feature Complete with Code Review and Tests  --> 達到100% code complete
之後QA便可以開始用這個build去做測試.

這裡可能只到前面2和3 之間的標準, 但是它定這個標準是要, 檢查是否code已經可以ready給QA做測試. 再加上它有用一些方法(code review and tests), 先做一些事先的檢查, 這樣會讓受測軟體的quality有基本的水準.

不知各位看倌, 你們的定義是什麼?

kojenchieh 發表在 痞客邦 留言(0) 人氣()

▲top
用10個步驟培養獲利體質
- Money 雜誌2009 1月號

1. 堅定投資風險資產的決心
風險資產就是訂存以外的商品, 如債卷, 基金, 股票, 房地產. 如果你的錢還是放定存, 那麼第一步就是解約, 僅保留20%續存, 其餘該思考要放在哪些風險資產上

2. 決定投資風險資產的預算和目標
別小看訂定預算和目標這件事, 首先要了解: 債卷的年報酬率通常低於5%, 基金有10%就算很好, 股票才有可能挑戰20%以上.
若無法承受波動刺激, 選擇債卷卻又訂定20%獲利目標, 當然就會失望.
決定預算也很重要, 若過度投資, 例如每月賺5萬, 卻要投資4萬, 一遇到劇烈帳跌時心情就緊張萬分, 甚至影響日常生計, 也非好做法

3. 話不多說開戶去
挑一家自己最方便或知名的銀行, 投信, 證卷戶, 開例投資戶頭, 立刻就去

4. 定期定額一檔基金吧
若沒有投資經驗, 建議挑1擋手續費低, 投資標的分散的指數型基金, 當最安穩的入門磚.
若資金允許, 建議可挑本國海外的指數型及債卷型基金, 共4檔

5. 邊投資邊學, 半年內有成效
買好標的後, 不能就放著不管, 但切記要冷靜觀看績效起伏, 了解漲跌緣由. 這是奠定基礎的關鍵期, 如果願意邊投資邊學習, 6個月內會看到成效.

6. 拿到獎金(額外收入)就來學習做積極成長型基金
有意外收入時, 不訪加買1檔機型基金. 因為最壞的情況下, 即使慘賠, 也不會傷筋動骨, 但卻能換來更寶貴的財富智商.

7. 學習風險管理
買了積極型商品, 風險管理變得更重要. 除了採定期定額外,  還要了解更多風險管理的知識. 例如要懂夏普指數(Sharp ratio)的意義, 它代表每承受一單位的風險可以獲得多少的超額報酬

8. 當報酬率開始穩定, 挑戰基金之外的商品
結束以上7個步驟後, 相信對基金已經熟悉, 可以進一步挑戰股票投資了

9. 嘗試將閱讀來的知識, 落實在應用
就像學會基礎英文後, 會嘗試想開口說英文, 自然而然地, 平時就會對財經新聞或書籍有興趣, 趁著這股熱情盡量吸收知識, 觀念, 然後嘗試用在自己的投資上.

10. 練習資產組合且定期審視
能做到這裡, 相信對投資方法已有了解, 且能做到掌握風險, 最後就是資產組合的平衡調整. 每隔1, 2年檢視投資標的, 可能初時偏重債卷基金, 小部分買進股票, 或許現在更熟練了, 可增加股票比重, 重新配置資產, 提升獲利速度.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

▲top
讓人驚訝的理財現象
- Money 雜誌2009 1月號

勝間和代是日本的暢銷女性作家, 出版了許多理財書籍. 其中2007年一口氣出了9 本書, 其中有4本名列Amazon 2008年上半年暢銷書前20 名.

她書中提出了不少讓人驚訝的理財現象, 讓我們一起來看看吧

現象 1. 把錢全放定存, 跟把錢全放在新興市場一樣危險
勝間說法: 把錢全放定存, 將會出現金錢常年難以增加的風險, 甚至還有銀行倒閉的可能, 這並沒有比把錢
都放新興市場來的好啊
Note:
- 這是強調一定要做投資的觀念
- 其實只要願意投資一些績優標的, 長期下來獲利肯並比放定存高

現象 2. 散戶忍不住賣掉的股票, 比願意續抱的股票, 多漲1倍
勝間說法: 這是一項柏克萊的統計, 散戶忍不部賣的股票如果漲5%, 先前忍不住不賣的股票平均就會長11.6%
Note:
- 這就是典型的"汰強留弱, 賺小賠大"
- 散戶經常犯的毛病, 賣掉強勢股, 死抱弱勢股

現象 3. 亞洲區18歲之前, 依靠教育給的金融素養, 是零
勝間說法: 歐美教育裡, 從小就有理財知識課程, 但亞洲卻幾乎沒有設計相關課程. 現代人不只自己有理財觀念, 更要教小孩有理財觀念

現象 4. 只要願意持續投資, 即使曾把賺來的都賠回去, 仍比放定存好
勝間說法: 許多人在低點把賺的錢都賠回去了, 但越是低點, 越該堅持繼續定期定額投資, 以後仍比只放定存賺得多

現象 5. 缺乏金融素養, 竟造成少子化
勝間說法: 如果不懂得使用錢賺錢, 就只能忙於工作賺錢, 收入有限, 誰敢生小孩? 甚至生不出小孩

現象 6. 散戶學技術面, 比學基本面更賺不到錢
勝間說法: 許多散戶不想瞭解基本面變化, 覺得學習技術指標比較簡單, 但經過統計, 學基本面的人比學技術面的獲利機會高
Note:
- 準確判斷基本面比較難, 但是了解企業體質和總體經濟是必備知識, 若能再搭配技術面, 可以克服更多盲點. 兩者並重, 相輔相成會更好.

現象 7. 高波動商品和穩定報酬商品, 長期投資後, 績效差不多
勝間說法: 經濟長期呈現穩定成長趨勢, 所以經歷高低起伏之後, 平均績效會和慢慢往上走差不多, 除非懂得波段操作. 所以, 投資穩定簡單就好.

現象 8. 撇除心理因素, 租房子比買房子好, 同地段的中古屋增值空間遠勝新成屋
勝間說法: 如果有一筆頭期款, 不如拿來投資, 增值空間通常比買房子快. 尤其買全新的大樓, 宣傳銷售成本都涵蓋在售價內, 並不划算.
Note:
- 在景氣的高峰, 租房子一定比買房子划算, 如果景氣下滑, 不仿考慮找有增值空間的房子
- 由於日本低利率, 高房價, 所以"租屋比買屋好"在日本比較為適用

現象 9. 沒做功課的散戶, 買股票還不如買彩卷
勝間說法: 沒做功課, 還想買股票賺錢的機率, 跟買彩卷差不多, 期望值一定是負的, 既然一定會賠錢, 還不如透過買彩卷來買個希望
Note:
- 但是如果只是道聽途說, 那真的乾脆什麼都不要買

kojenchieh 發表在 痞客邦 留言(0) 人氣()

▲top
«1...280281282 283284...311

Close

您尚未登入，將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

reload

請輸入左方認證碼：

看不懂,換張圖

請輸入驗證碼