超低利率將帶來4大改變
2009 Money 雜誌 1月號

1. 定存不再收歡迎
- 低利率使資金離開銀行, 進入消費與投資領域

2. 汽車及房市可望受益
- 人們增加消費及投資意願, 主要會反映在哪裡呢? 從理性角度分析, 主要會反映在需要舉債進行大額消費上. 畢竟, 只有不到1%的超低利息, 將激發人們對於原先高價物品需求, 潛意識裡的耐久財渴望將蠢蠢欲動.
- 其中最主要的投資就是汽車和房市. 這就是為什麼每當有降息消息傳出, 股市中營建及資產類股, 就會上漲反應的原因所在.

3. 債卷將逐漸失去吸引力
- 隨著各國央行利率已處歷史低點, 甚至逼近零利率而降無可降的窘境, 短期卷及長期卷殖利率對於降息預期的反應已經鈍化, 亦即債券價格很難再續漲.
- 短期內, 債卷型基金可能還有一波小行情, 但是2009年基本上不會再出現先前的牛市; 加上政府大量發行新債, 將增加市場籌碼的供應, 目前的新政府發行價格已經充分反映, 甚至過度反應寬鬆貨幣政策, 未來債卷將逐漸失去吸引力.

4. 股市本益比將提高
- 假如你以20元買進一檔股票, 且該檔股票每股盈餘(EPS)為1元, 則本益比為20倍( = 股價 / EPS). 同樣的, 如果將這20元存入銀行, 而銀行的年利率是5%, 則每年也可以收到利息1元. 也就是說, 投資本益比20倍的股票, 與投資年利率5%的定存, 有相同的報酬率.
- 但是利率降到很低, 股市的本益比將順勢提高, 使得目前的股價看起來都顯得物美價廉, 資金流向股市等投資領域是必然的趨勢
- 目前是因為股市還在打底, 舵數投資人沒有信心, 只要股市出現利空不再下跌, 開始有落底的跡象, 資金自然會流入股市投資, 產生資金行情.

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

如何讓QA樂意幫助RD成功

My 2009 advice for programmers (on making - or keeping - testers happy)
http://blogs.msdn.com/alanpa/archive/2009/01/03/my-2009-advice-for-programmers-on-making-or-keeping-testers-happy.aspx


有人問到作者
As a programmer I don't like to see bugs (and I don't like the QA ranting about the qaulity of my work either).
Could you post your "2009 advice to programmers" on how to make testers happy

作者首先對於ranting這個字有點concern, 認為提問者可能和QA之間的溝通出了一點問題, 也可能是把bug report看得太嚴重了. 作者認為bug report只是呈, 現有關於proudct quality的資訊, 但是這並不是RD quality的資訊. 它只是要幫助product quality要更好.

個人我認為有bug並不是完全和RD有關, 有時候錯誤的requirement, tight schedule, 和溝通上的落差, 都會造成有bug出現. 只是每個bug要會要有負責處理的owner, 但並不是代表這owner就是始作庸者, 或是代表他的quality , performance不好.

作者接下列出了一些注意事項, 讓RD可以注意, 以幫助RD和QA cowork的更順暢

1. 不要對QA大呼小叫的
- They’re not bottom feeders lucky to have a job, and they’re not developers who couldn’t cut it.
- Most of us have chosen to be testers because we’re good at it and it gives us an opportunity to have a huge impact on software quality.
- The better we work together, the better job you’re going to do in the end.
- Software development is a joint effort between programmers and testers – if you want to be successful, you need a good relationship with your testers.

2. 要撰寫Unit Tests
- Don’t make it easy for me to find bugs.
- Testers aren’t asking you to find every single bug, but at least test enough of your own code that testers won’t find bugs in basic functionality.
- The harder it is for testers to find bugs in your code, the more they will respect you.
- When testers begin finding complex bugs that you never thought could exist, you will respect them more too.

3. 多思考Testability
- Testable software is well designed software.
- Consider the SOCK model (Simple, Observable, Control, and Knowledge).
- Think about testing during design and implementation – ask yourself “’how will we know this works?”

4. 不要怕會衝突
- Conflict is fine (and expected), but everyone needs to feel that their voice is heard.
- When you disagree, explain why you disagree, and don’t expect to resolve every conflict.

5. 要多溝通
- Spend time talking about challenges of your roles.
- Understanding the other side helps you both do your job better.

6. 不要認為Bug Report是針對個人而來的
- Note to testers: bug reports are NOT your avenue for belittling developers
- Bug reports are a necessary side effect of the testers job.
- Bugs are just bits of information that you need to act on.

7. 不要因為QA找到你程式中的Bug就覺得他們很討厭
- You should be surprised, or maybe even embarrassed depending on the details of the issue.

8. 不要覺得不好意思去提供一些測試的建議
- E.g. "It's going to be important to test how the string fields are translated between component x and component y", or "I’m worried that the component we’re leveraging from team z will cause compat problems, can you spend some time investigating?"


當然啦, 我個人認為QA某些事情上, 也是有努力的空間. 下次來找找, 是否有RD對QA的建言.

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

為什麼需要做Exploratory Testing

explaining exploratory testing
http://blogs.msdn.com/james_whittaker/archive/2009/01/08/explaining-exploratory-testing.aspx

January 08, 2009
Posted
by James Whittaker
Published in JW on Test

公司最近有介紹Exploratory Testing 的sharing, 在會議中發現大家幾乎都不知道這是什麼, 因此希望這篇文章可以多幫忙了解一點為何要做Exploratory Testing


軟體測試之所以複雜, 是在於它有過多可能的組合. (在我認為是接近無限多):
- inputs
- code paths to state
- operational environment.
這三種的情況, 前兩種的數量接近無限多, 第三種是很多, 所以combine起來後, 狀況幾乎是無法想像的多.

所以不管你採取什麼方法, Scripted Testing (也就是事先規劃) 或是 Exploratory Testing (一邊學, 一邊規劃, 和一邊測試), 要完整測試是不可能的事

然而Exploratory Testing的好處是, 讓QA能在測試過程中, 根據他所學到, 所收集到的, 然後來決定接下來要整麼調整, 怎麼進行接下來的測試. 而不是只是follow up之前規劃好的test cases 或是test plan.

這是最主要比Scripted Testing(泛指事先規劃的方法)佔優勢的地方.

你可以想像, 如果你若是要在季賽前, 要預測 Super Bowl (美國橄欖球超級杯大賽) or Premier League(英超聯賽)的贏家, 你會不會認為是一件非常難的事情.

因為你需要觀察team如何來運作, 進攻; 或是主力球員是否整季都健康, 沒有受傷; 或是教練和球員整合程度. 這些都是變因, 這些資訊會隨著賽季的展開, 你才能逐步調整你的預測, 然後會對的機會, 才會越來越高.

同理, 再軟體測試上也是一樣, Exploratory Testing也是在過程中, 一方面根據之前的歷史資料, 所學會的domain knowledge, 再加上目前狀況的需求, 不斷再調整所要進攻的方向, 已確定你所要測試的重點

所以有效的使用Exploratory Testing, 可以幫助你在面對軟體測試複雜的狀況, 能夠更有信心去deliver quality software.

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

是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) 人氣()

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) 人氣()

Close

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

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

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

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

reload

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼