如何利用Microsoft Hyper-V來進行自動化測試
Automating Software Testing with Microsoft Hyper-V
http://www.developer.com/tech/article.php/3785891
Posted by Jani Jarvinen
Published in Developer.com
每次在作測試時, QA很大的effort是在準備環境, 不但要乾淨的環境, 還要各式各樣的環境, 所以常讓QA覺得生命為何要浪費在這樣無意義的事情上.
因此當VMWare出來時, 讓software testing看到了一道曙光. 尤其它提供了API,讓你可以自動化這些流程時, 更是讓QA高興的不得了.
就在這時候, Microsoft也不甘示弱, 也加入這場戰場, 推出了Virual PC, 之後還有Hyper-V. 現在推出了Hyper-V Server 2008, 和VMware的 ESXi很像, 它是一個免錢的軟體.
因此有了Hyper-V Server 2008, 再加上Visual Studio Team Foundation Server (TFS) 和 Team Build 的功能, 你就能做到 one click, 就能將compile, deploy和testing畢其功於一役.
這裡有篇介紹如何使用Hyper-V來做自動化測試的文件, enjoy it!!
kojenchieh 發表在 痞客邦 留言(0) 人氣()
IDEO 的相關資料
公司花了十萬元讓我們去上Innovation workshop, 回來之後, 老闆要我們給個交代, 希望能介紹一下, 這堂課的賣點在哪裡. 因此花了一些時間, 整理了一些有關IDEO的相關資料, 發現真是多到不行, 看起來要花好多時間用功一下, 否則Steve問起來, 可是會丟臉的.
1. IDEO系列文章
From 美感經濟與風格社會的對話 - http://www.aestheticeconomy.com/blog/
IDEO系列 1 : 創新 + 美學 = IDEO
http://www.aestheticeconomy.com/blog//?p=141
IDEO系列 2 : 從 IDEO 到 McKinsey 的觀察:設計的力量，挑戰管理權威
http://www.aestheticeconomy.com/blog//?p=143
IDEO系列 3 : 從設計到管理的觀察: 讀IDEO的「決定未來的10種人」
http://www.aestheticeconomy.com/blog//?p=150
IDEO系列 4 : 當設計思考者，不需科班畢業
http://www.aestheticeconomy.com/blog//?p=225
IDEO系列 5 : 設計思考，始終來自於人性
http://www.aestheticeconomy.com/blog/?p=226
IDEO系列 6 : 51種啟發創新思考的方法 (IDEO Method Cards)
http://www.aestheticeconomy.com/blog//?p=254
IDEO系列 7 : 誰讓哈佛商業評論與美學經濟俱進
http://www.aestheticeconomy.com/blog/?p=261
IDEO系列 8 : 關於設計思考的五個問題
http://www.aestheticeconomy.com/blog/?p=349
2. Inside IDEO
美國ABC廣播公司的Nightline對IDEO所製作的特別節目, 該報導除了一般性的介紹了IDEO之外, 還請IDEO組成一個團隊, 在數日之內進行購物推車設計專案, 展示他們的設計流程, 風格與方法。
Part I
http://tw.youtube.com/watch?v=z6z-3ejvvGE
Part II
http://tw.youtube.com/watch?v=THz6kbcgw9E
Part III
http://tw.youtube.com/watch?v=qTf18QAEkcY
3. Useful Articles
a. 四大拼圖，拼出世界頂尖設計版圖
http://n.yam.com/view/mkmnews.php/553192/1
b. IDEO 方法圖卡的認知組織
http://taiwan.chtsai.org/2008/05/08/ideo_fangfa_tuka_de_renzhi_zuzhi/
c. 六大原則：SUCCESs 清單──原則五：情緒
http://datacu.blogspot.com/2009/01/success_2081.html
d. IDEO創新的3個秘訣
http://jr1221.spaces.live.com/blog/cns!F1DD5BF537DB55F1!276.entry
e. IDEO設計公司 - 美國設計公司的演變與地緣特質
http://design.twmail.org/paper/ideo.pdf
f. Design Thinking. 從產品設計到創意顧問的IDEO
http://www.wretch.cc/blog/yellowbird54/8753682
http://www.wretch.cc/blog/yellowbird54/8820991
g. IDEA物語
http://guo.ba.ntu.edu.tw/%E6%95%99%E5%AD%B8%E8%AA%B2%E7%A8%8B/%E9%80%B2%E4%BF%AE%E6%8E%A8%E5%BB%A3%E7%AE%A1%E7%A0%94%E7%8F%AD/%E7%A7%91%E6%8A%80%E8%88%87%E7%87%9F%E9%81%8B%E7%AE%A1%E7%90%86/%E8%AC%9B%E7%BE%A9%E5%92%8C%E4%BD%9C%E6%A5%AD/team7_IDEA%E7%89%A9%E8%AA%9E.pdf
h. Bill Moggridge：Service Design
http://imcreating.blogspot.com/2008/12/1216-bill-moggridgeservice-design.html
4. Web Site
a. IDEO Labs
IDEO 開了一個 Blog，這個 Blog 叫做 IDEO Lab，比較有趣的是，它們的 Lab 的第一個計畫竟然是做 Multitouch。
http://labs.ideo.com/
b. IDEO Web Site
http://www.ideo.com/
5. Books
a. The Ten Faces of Innovation: IDEO's Strategies for Defeating the Devil's Advocate and Driving Creativity Throughout Your Organization
by Thomas Kelley (Author), Jonathan Littman (Author)
http://www.amazon.com/Ten-Faces-Innovation-Strategies-Organization/dp/0385512074/ref=sr_1_1?ie=UTF8&s=books&qid=1237596879&sr=1-1
b. The Art of Innovation: Success Through Innovation the IDEO Way
by Thomas Kelley
http://www.amazon.com/Art-Innovation-Success-Through-IDEO/dp/186197583X/ref=sr_1_12?ie=UTF8&s=books&qid=1237596879&sr=1-12
c. Designing Interactions
by Bill Moggridge
http://www.amazon.com/Designing-Interactions-Bill-Moggridge/dp/0262134748/ref=sr_1_8?ie=UTF8&s=books&qid=1237596879&sr=1-8
kojenchieh 發表在 痞客邦 留言(0) 人氣()
Agile軟體開發程序的缺點
Disadvantages of Agile Software Development
http://www.agile-software-development.com/2007/09/disadvantages-of-agile-software.html
Posted by Kelly Water
Published in All About Agile
作者說不要懷疑他, 他是道道地地Agile的fan.
雖然Agile有很多好處, 但是他也是一定有不少缺點
所以當你在採用Agile時, 你一定要知道他當初要解決的問題是什麼, 或是為了達到什麼目的. 這樣你才可檢查這樣的東西是否適合你, 你也才知道一些trade-off.
這裡是作者列出一些, 在agile中不錯的practices, 但是它卻帶來一些問題:
1. 在開發過程要求顧客積極加入及緊密合作
- However these principles are very demanding on the user representative's time and require a big commitment for the duration of the project.
2. 在開發過程, 需求會逐漸浮現及演進
- There are two big flip sides to this principle though.
* One is the potential for scope creep, which we all know can create the risk of ever-lasting projects.
* The other is that there is much less predictability, at the start of the project and during, about what the project is actually going to deliver.
- This can make it harder to define a business case for the project, and harder to negotiate fixed price projects.
- Without the maturity of a strong and clear vision, and the discipline of fixing timescales and trading scope, this is potentially very dangerous.
3. 簡潔的需求就已經足夠了
- However this can mean less information available to new starters in the team about features and how they should work.
- It can also create potential misunderstandings if the teamwork and communication aren't at their best, and difficulties for team members (especially testers) that are used to everything being defined up front.
- The belief in agile is that it's quicker to refactor the product along the way than to try to define everything completely up front, which arguably is impossible.
- And this risk is managed closely through the incremental approach to development and frequent delivery of product.
4. 測試是被整合到整個開發過程
- However it does imply that testers are needed throughout the project and this effectively increases the cost of resources on the project.
- This does have the effect of reducing some very significant risks, that have proven through research to cause many projects to fail.
- The cost of a long and unnpredictable test phase can, in my experience of waterfall, cause huge unexpected costs when a project over-runs.
- However there is an additional cost to the project to adopt continuous testing throughout.
5. 經常交付產品給客戶
- The users or product owner needs to be ready and available for prompt testing of the features as they are delivered and throughout the entire duration of the project.
- This can be quite time-consuming but helps drastically to ensure a quality product that meets user expectations.
6. 綿密的iterations/sprints
- Finally, common feedback is that agile development is rather intense for developers.
- The need to really complete each feature 100% within each iteration, and the relentlessness of iterations, can be mentally quite tiring so it's important to find a sustainable pace for the team.
不知各位看倌, 你覺得這些是否也是你的問題?
kojenchieh 發表在 痞客邦 留言(0) 人氣()
使用白板所帶來的好處
The Power of a Whiteboard
http://www.agile-software-development.com/2009/03/power-of-whiteboard.html
Posted by Kelly Water
Published in All About Agile
Agile的開發團隊通常使用一些low-tech, 手動的方式來追蹤他們的工作. 像是用便利貼來記載工作項目, 用手繪的burndown chart, 或是用手繪的architecture等等
你或許會很好奇, 像這樣高科技的產業, 應該有一堆現成的project management tools, 或是一些為特定目的所建造的工具可以使用, 會何會用這樣low-tech的方式呢?
作者認為白版提供很多好處, 是這些軟體工具所比不上的.
1. 白板讓大家都看得見
- When you see something in print, somehow it seems more real. I guess because it's physical.
- A large number of post-it notes on a whiteboard looks like a lot of work.
- You can show some information like: Sprint Status, Burndown Chart
2. 白板有著無限的彈性
- You can put literally anything you like on it.
- Unlike an electronic system, there are never any constraints.
3. 白板可以快速, 有效的被修改
- You could completely reoarganise a set of cards in just a few moments.
- Or sketch something important in seconds.
4. 讓你覺得有形的
- For people that like tactile, it feels good to move a card to done.
- You feel a sense of ownership when you pick up a card.
5. 它也讓你感到很新穎, 新奇的
- When a team starts doing agile - and they create great visibility using the whiteboard - it's remarkable how many people want to come and look.
- The whiteboard is interesting. It's interesting to look at. And interesting to talk about. When someone walks you through it, it's actually enjoyable.
6. 白板提供一個可以一起合作, 一起討論的地方
- It's a focal point.
- Like a campfire in days gone by. Or a fireplace in your lounge.
- Most team discussions happen round the whiteboard. Discussions about progress. Discussions about issues. Discussions about design.
7. 在白板上, 不同團隊會呈現出不同的文化
- The team can express itself through the things it puts on its whiteboard.
- It starts to show the character of the team, and therefore helps to create a visible sense of team spirit.
作者也提到他並不是反對使用工具, 只是他認為工具是用來輔助白板, 而不是取代它. 有些事情是白版無法做的, 像是keeping track of longer lasting information, doing calculations, searching等等.
kojenchieh 發表在 痞客邦 留言(0) 人氣()
招募SDET來當QA是必要的嗎? 正確的嗎?
我想這篇真的很值得大家看一下.
尤其是你在掙扎, 是否要效倣Microsoft hire大量的SDET來做QA的工作時, 這裡提出了不同的見解, 提出了這樣的作法的盲點在哪裡.
此外在後面, 作者和James Bach所提到QA和RD想法上的差別, 我想是非常一針見血的見解. Enjoy it
What's an SDET - II
http://xndev.blogspot.com/2009/03/whats-sdet-ii.html
March 06, 2009
Posted by Matthew
Published in Creative Chaos
我想很多人都看過"The art of software testing", 在書中最有名的例子, 是測試一個三角形的程式. 讓我先回顧一下這個題目
有一個程式, 會讀入三角形的三邊長, 然後會輸出這個三角形是何種三角形. 比如說, 正三角形, 等腰三角形, 一個普通的三角形, 和不是三角形等等.
作者認為, 書中的回答是非常RD style的答案, 為什麼呢? 作者解釋如下:
作者認為如果你只是注意input 和expected results, 那你心中只看到這樣的東西
my $triangle_type = get_triangle_type($sidea, $sideb, $sidec);
然後你會做以下的測試
- The basic equivalence classes,
- The boundaries,
- Maybe measure statement coverage - maybe even branch coverage,
- Perhaps have a bunch of negative tests like entering words instead of numbers,
- A "length" of a negative number
- In the days of MS-DOS where you had a single user sitting at a single computer typing in one value at a time, that might be just fine.
但是作者認為, 在現在的環境中, 只做對了一半. 因為通常我們的程式, 會放在web上執行, 或是做成 web service讓別人呼叫. 因此你可能還需要考慮以下問題
- Does it render correctly in all browsers? IE6, IE7, FF2, FF3, Safari?
- Does it look pretty? Is the user interface usable?
- What happens if I resize the browser? Does the new rendering make sense?
- If I click tab through the various inputs instead of using the mouse, does the change in order make sense?
- If I press the "ENTER" or "RETURN" key, does that trigger the submit button?
- What happens if I click "submit" twice in a row - really fast?
- What happens if, after I click submit, I click the back button? Do I go back to the main screen or do I get one of those bizarre "This page was generated dynamically do you want to re-post?" error messages?
- What if I am visually impaired? Can I turn up the font or does the Cascading Style Sheet "lock" down the user experience? If I can crank up the font is it visually appealing?
- What if I am blind? Can I use the application by a tool for the blind like Lynx? Do all of the images have "alt=" tags?
- Is the web service reasonably fast? What if it's used by 100 users all at the same time? (Note: This was never a problem on MS-DOS, where you only had one user at a time)
- Can I run the application on my 1024x600 netbook? The ads said my netbook was good "for web surfing"
- Can I run the application on my Cell Phone?
- If I come in from a chinese, korean, or italian system but I know english, does the user experience make sense?
- What if I don't know English? Should our software be localized? If yes, what localizations?
這就是會什麼作者覺得書上的答案是不夠的, 這個三角形的例子是不夠理想的, 因為它只著重在某一類型的測試, 而忽略了其他類型的測試.
所以作者認為如果你只是hire RD來當 QA, 其實是一件很危險的事. 因為他很可能都只是注意到前半部的測試 : code, code, and statement coverage, 而不會去想到後半部的測試.
作者還認為, 我們在前半部份的測試,通常都做的很好. 但是對於後半部的測試, 我們經常是缺乏根據使用者的經驗, 來建立一些在real world會遇到的測試
以下是作者認為Microsoft對QA的態度
===============================================
Now, the Microsoft Guys claim to be doing it right.
They want Software Design Engineers in Test (SDETs) who can do *both* entry-level developing *and* critical investigation of software under test - and there are some people who fit into that category.
But that's like saying you want excellent sprinters who are also world-class distance runners - while they do exist, there just ain't that many of those people on the planet.
Those that are here can usually find gainful employment, and not all of them want to live in Washington State, China or India.
The result is that, as an employer, you'll either have to (A) Pay an relative large sum for these people, (B) Have a bunch of open positions while you look for people with the right mix, or (C) Compromise, hiring people who are, for example, good devs you think might make good testers.
This runs the serious risk of developer myopia.
===============================================
之後作者和他同事James Bach (有名的software testing作者)討論過, 以下是Jame Bach的意見
The words that you quoted [Matt talking about MS's view of testers] represent an attitude that systematically misunderstands testing as a purely (or primarily) a technical activity the object which is to produce "test cases." I too had that attitude, early in my career.
I grew out of it as I came to understand, through my experiences as a test manager, that a test team becomes stronger when it hosts a variety of people with a variety of backgrounds.
Through the ordinary action of teamwork, a diverse group of thinkers/learners exploits the knowledge and skills of each for the benefit of all.
My attitude about testing is deeply informed by a study of cognitive psychology, which is the study of how people think, and epistemology, which is the study of how people can know what they know. ...
When you approach testing not as hot-dogging with test tools or techniques, but rather as a process of human minds encountering human artifacts and evaluating them in human terms for other humans, you eventually realize that the testing process is harmed when any one point of view or way of thinking comes to dominate it.
I would like at least one programmer on my test team. Maybe a few.
In some cases (such as in testing development tools) I will need everyone to be a programmer.
However, I do not treat programming ability as the center of gravity for testing.
Instead I look for rapid learning, high tolerance for uncertainty, and general systems reasoning.
Even then, I don't need EVERYONE to be good at those things.
=======================================================
之後是作者的想法:
I'd use different rhetoric and be less critical, but I understand what James is saying.
As testers, we tend to have developer-envy.
The reality is that the two skills are separate, distinct, and complementary.
(Unless, say, you are testing a compiler or a debugger. Are you?)
Now, can a non-developer-tester be a more effective by picking up a little code?
Absolutely. I have an undergraduate degree in Math/CS and a Master's in CIS, of which I am extremely proud - not to mention a decade with a title of developer on my business card.
AND it took me years to fight my way through developer myopia to see the whole picture of software testing.
Developers tend to think in terms of automatable business processes - when exactly what needs to be done up front isn't clear, developers claim that the requirements are "inconsistent" and refuse to program.
The whole picture of testing might include some repeatable elements, but it also includes empirical processes - which adapt through learning as they happen.
This is not a straightforward business process to automate. Developer-Envy doesn't help our craft, it hurts it.
kojenchieh 發表在 痞客邦 留言(0) 人氣()
