目前分類：測試管理 (19)
- Mar 01 Fri 2024 10:29
測試管理都在管什麼
- Jul 19 Sun 2009 06:21
如何評量測試人員的效率
如何評量測試人員的效率
How to measue Tester performonce
http://www.softwaretestingclub.com/profiles/blogs/how-to-measue-tester
June 15, 2009
Posted by kashif ali
- May 25 Mon 2009 09:22
十個減少軟體測試成本的方法
十個減少軟體測試成本的方法
10 ways to reduce cost of software testing
http://shrinik.blogspot.com/2009_04_19_archive.html
Sunday, April 19, 2009
Posted by Shrini Kulkarni
Published in Thinking Tester
- May 05 Tue 2009 16:18
如何評估測試人員績效
如何評估測試人員績效
Assessing Tester Performance
http://blogs.msdn.com/imtesty/archive/2009/04/28/assessing-tester-performance.aspx
2009 April 28
Posted by Bj Rollison
Published in I.M. Testy
- Apr 22 Wed 2009 15:37
QA和RD如何在早期就開始合作
QA和RD如何在早期就開始合作
有人說若是QA早一點開始加入專案, 應該可以幫助專案品質變好, 可以幫忙釐清需求, 可以縮短測試時間. 聽起來真的好處多多.
可是真的是這樣嗎? 我想以各位看倌多年的經驗, 應該會覺得不會這麼容易. 是的, 是不容易, 但是原因是什麼呢?
就我個人觀感第一個原因是mindset, 是的, 是mindset.
像我現在在run Agile, 如果大家對Agile有所認識, 應該知道Agile強調就是mindset的轉變, 如果心態沒有轉變成, 要因應變化而積極作調整, 那你在執行的任何practice都因而事倍功半, 最常見的就是便成mini waterfall. 因為我們只是把一個大的, 長的開發時程, 便成一個為期2 weeks 或4 weeks的小型專案. 事實上幫助會有限.
- Apr 17 Fri 2009 09:26
Test Case所涵蓋的範圍足夠了嗎?
Test Case所涵蓋的範圍足夠了嗎?
很多人常常問, 如何得知test cases是否已經開得足夠了, 是否已經cover所有的範圍了, 這還真的是很難回答的問題, 但是也是各很值得大家一起討論的問題.
因此小弟在此先拋磚引玉, 先列出一些個人的看法, 希望大家能夠一起參予討論, 貢獻一下不同的想法
1. Requirement - Test Cases Mapping
常見的手法, 是建立requriement/design 和test case的對應關係. 這樣你便可以知道, 是否每個requirement已經有對應的test cases. 如果沒有對應的部份, 便要加開 test case
- Apr 08 Wed 2009 13:48
如何當一個成功的Test Manager
如何當一個成功的Test Manager
10 Things You Might Not Know About Beging a Successful Test Manager
May, 2008
Posted by Rick Craig
Published in Better Softeware
1. 要記得鼓勵你的員工
- Mar 18 Wed 2009 09:30
招募SDET來當QA是必要的嗎? 正確的嗎?
招募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.
我想這篇真的很值得大家看一下.
尤其是你在掙扎, 是否要效倣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.
- Feb 03 Tue 2009 09:23
Software Testing Career Development
Software Testing Career Development
http://watirmelon.wordpress.com/2008/03/13/software-testing-career-development/
對於在軟體測試上的職涯規劃, 作者非常主動地鞭策自己一直往前進. 他認為不管公司有沒有提供這樣的協助或是規劃, 自己都有責任對自己專業生涯發展做些事情.
他發現Ian Clatworthy 提出了一個 professional development framework, M.E.T.A. - Management, Engineering, Technology and Applications.
他根據這個framework加以改良, 變成Leadership, Concepts, Business-focus & Tools. 在這裡面提出在生涯發展規劃中, QA應該要具備哪些能力.
A. Leadership (Ian’s Management)
作者認為不管你是不是manger, supervisor, 或者甚至你都不需要管人, 你都會需要leadership的能力. 因此他將Ian的mangement做了些調整, 變成是leadership. 以下是作者認為要有的leadership
1. Using the right side of my brain
- being organised, tidy & efficient (following concepts like 5S), being emotionally intelligent and aware, developing creative solutions.
2. Having a project management focus
- following sound project management techniques and conducting each bit of work as a small project.
3. Writing Well
- following known writing guidelines. Documenting every bit of work. Sharing all knowledge and information.
4. Communicating Well
- Documenting every bit of work. Communicating progress and issues in the right format at the right time.
5. Team Building
- establishing productive relationships with members of teams working in and with. I can’t emphasise how important this is.
6. Finding Informal Career Guiders
- always indirectly looking out for people who you can chat to informally about career stuff. This is where I have discovered great leadership styles and techniques. I call these people career guiders because I really hate the word ‘mentor‘.
7. Being ethical
- Making sure I provide value and I am honest in everything I do.
8. Sticking up for others you work with
- Making sure that your fellow team mates are well supported.
B. Concepts (Ian’s Engineering)
對於software engineering, 作者比較重視software 部分. 也就是包含software design, development and testing相關的理論和觀念.
如果你能有正確的觀念, 那表示你對事情將會有正確的認知和認識
這些觀念通常你在大學中, 就已經學習過, 那些知識通常都歷久不衰.
1. Understanding Software Development Methodologies:
- how IT software design and development works as a whole.
2. Understanding Software Projects:
- how IT software projects work.
3. Understanding Programming:
- knowing programming concepts and techniques.
4. Understanding Testing:
- understanding testing best practices, test driven development, test automation, acceptance testing.
5. Understanding User Centred Design:
- focusing on usability and designing for users. Paper prototyping and iterative design.
6. Understanding Design:
- understanding general design principles.
C. Tools (Ian’s Technology)
作者曾經打算延用Ian的technology這個term, 但是最後他還是覺得tools比較合適. Tools和concepts的差別是, tools是用來支持 Concepts的實踐, 並且tools可能換一直更新, 但是concept通常是保持不變的.
作者目前比較著重在用open source 的tools, 因為他不用錢, 品質也不錯.
1. Programming Languages:
- such as Ruby, Python, Jython.
2. Testing Tools:
- such as Watir, OpenQA.org and homebrew test automation tools.
3. Collaboration Tools:
- such as wiki’s, defect management, blogs.
4. Versioning Tools:
- such as SVN, Bazaar VCS.
此外還一些技術(不算是tools), 作者認為也值得了解
* Ajax (Rich Internet Applications)
* Web 2.0
* Social Networking
* Tag-based Folksonomies
* RSS
D. Business-focus (Ian’s Applications)
作者認為了解目前工作上的business是如何運作, 也是非常重要的一件事情. 通常IT人員不了解, 也不太尊重他們所工作的business.
1. Understanding business goals:
- why I am employed in the first place.
2. Understanding business applications:
- what they do and how they fit into the business processes.
3. Understanding business processes:
- how business is conducted, with or without IT.
4. Understanding how business and IT collaborate and partnership:
- Hoping that the tail doesn’t wag the dog!
5. Providing value to the business:
- continuing to be employed.
6. Keeping up to date with the business:
- knowing what the business industry/competition is doing and about the other happenings in the business domain.
7. Understanding how executive management operates:
- because they usually pay you and maybe you would like to be there someday.
不知道各位看官, 你自己是如何規劃你的職涯發展? 或許和作者相去甚遠, 但是這也無所謂, 指要不要完全都沒有想過就好. 重點是要自己對自己負責, 千萬不要等公司幫你規劃, 那是會拖很久的!!
http://watirmelon.wordpress.com/2008/03/13/software-testing-career-development/
對於在軟體測試上的職涯規劃, 作者非常主動地鞭策自己一直往前進. 他認為不管公司有沒有提供這樣的協助或是規劃, 自己都有責任對自己專業生涯發展做些事情.
他發現Ian Clatworthy 提出了一個 professional development framework, M.E.T.A. - Management, Engineering, Technology and Applications.
他根據這個framework加以改良, 變成Leadership, Concepts, Business-focus & Tools. 在這裡面提出在生涯發展規劃中, QA應該要具備哪些能力.
A. Leadership (Ian’s Management)
作者認為不管你是不是manger, supervisor, 或者甚至你都不需要管人, 你都會需要leadership的能力. 因此他將Ian的mangement做了些調整, 變成是leadership. 以下是作者認為要有的leadership
1. Using the right side of my brain
- being organised, tidy & efficient (following concepts like 5S), being emotionally intelligent and aware, developing creative solutions.
2. Having a project management focus
- following sound project management techniques and conducting each bit of work as a small project.
3. Writing Well
- following known writing guidelines. Documenting every bit of work. Sharing all knowledge and information.
4. Communicating Well
- Documenting every bit of work. Communicating progress and issues in the right format at the right time.
5. Team Building
- establishing productive relationships with members of teams working in and with. I can’t emphasise how important this is.
6. Finding Informal Career Guiders
- always indirectly looking out for people who you can chat to informally about career stuff. This is where I have discovered great leadership styles and techniques. I call these people career guiders because I really hate the word ‘mentor‘.
7. Being ethical
- Making sure I provide value and I am honest in everything I do.
8. Sticking up for others you work with
- Making sure that your fellow team mates are well supported.
B. Concepts (Ian’s Engineering)
對於software engineering, 作者比較重視software 部分. 也就是包含software design, development and testing相關的理論和觀念.
如果你能有正確的觀念, 那表示你對事情將會有正確的認知和認識
這些觀念通常你在大學中, 就已經學習過, 那些知識通常都歷久不衰.
1. Understanding Software Development Methodologies:
- how IT software design and development works as a whole.
2. Understanding Software Projects:
- how IT software projects work.
3. Understanding Programming:
- knowing programming concepts and techniques.
4. Understanding Testing:
- understanding testing best practices, test driven development, test automation, acceptance testing.
5. Understanding User Centred Design:
- focusing on usability and designing for users. Paper prototyping and iterative design.
6. Understanding Design:
- understanding general design principles.
C. Tools (Ian’s Technology)
作者曾經打算延用Ian的technology這個term, 但是最後他還是覺得tools比較合適. Tools和concepts的差別是, tools是用來支持 Concepts的實踐, 並且tools可能換一直更新, 但是concept通常是保持不變的.
作者目前比較著重在用open source 的tools, 因為他不用錢, 品質也不錯.
1. Programming Languages:
- such as Ruby, Python, Jython.
2. Testing Tools:
- such as Watir, OpenQA.org and homebrew test automation tools.
3. Collaboration Tools:
- such as wiki’s, defect management, blogs.
4. Versioning Tools:
- such as SVN, Bazaar VCS.
此外還一些技術(不算是tools), 作者認為也值得了解
* Ajax (Rich Internet Applications)
* Web 2.0
* Social Networking
* Tag-based Folksonomies
* RSS
D. Business-focus (Ian’s Applications)
作者認為了解目前工作上的business是如何運作, 也是非常重要的一件事情. 通常IT人員不了解, 也不太尊重他們所工作的business.
1. Understanding business goals:
- why I am employed in the first place.
2. Understanding business applications:
- what they do and how they fit into the business processes.
3. Understanding business processes:
- how business is conducted, with or without IT.
4. Understanding how business and IT collaborate and partnership:
- Hoping that the tail doesn’t wag the dog!
5. Providing value to the business:
- continuing to be employed.
6. Keeping up to date with the business:
- knowing what the business industry/competition is doing and about the other happenings in the business domain.
7. Understanding how executive management operates:
- because they usually pay you and maybe you would like to be there someday.
不知道各位看官, 你自己是如何規劃你的職涯發展? 或許和作者相去甚遠, 但是這也無所謂, 指要不要完全都沒有想過就好. 重點是要自己對自己負責, 千萬不要等公司幫你規劃, 那是會拖很久的!!
- Jan 14 Wed 2009 09:43
是Bug? 還是Feature?
是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它. 而不是一開頭就拿這句話來搪塞.
不過, 講了半天, 我也承認人性是很難克服的. 包括我自己, 在壓力大的狀況下, 很容易挑一條容易走的路, 而不一定是正確的路來走....... 所以, 也無法太則怪別人.
喲哪桑在他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它. 而不是一開頭就拿這句話來搪塞.
不過, 講了半天, 我也承認人性是很難克服的. 包括我自己, 在壓力大的狀況下, 很容易挑一條容易走的路, 而不一定是正確的路來走....... 所以, 也無法太則怪別人.
- Dec 18 Thu 2008 09:09
Microsoft 對QA人員的策略
Microsoft 對QA人員的策略
最近我們和Microsoft有密切的合作, 最主要是想增進我們公司整體軟體開發的能力. 在昨天的會議中, 提到了Microsoft對QA人員的策略, 它讓我想到之前看過的一篇文章. 第一次瞄到時, 還不是很注意. 現在看起來, Microsoft很早就打定這樣的主意.
Test Automation - Takes toll of Microsoft Testers ....
http://shrinik.blogspot.com/2006/08/test-automation-takes-toll-of.html
這篇blog文是在2006年寫的, 作者(他以前也是微軟員工)說他看到Seattle times在 2004 Jan報導, 提到Microsoft lay off了Windows group 中62個testers
http://seattletimes.nwsource.com/html/microsoft/2002155249_mslayoffs20.html
報導中寫著, lay off的原因如下
1. They had automation so testers not required.
2. They need to cut cost - either send jobs to India (low cost option) or aggressively automate...
作者第一時間覺得很可悲, Microsoft居然走到這地步, 居然相信automation可以取代人腦. 不過因為沒有任何官方回應, 或是內部小道消息. 作者也無法確認Microsoft真正的目的為何. 因此作者post這篇文章, 希望內部知情人士能透露一二.
於是就有一些人回應如下:
====================================
Anonymous said...
No testers were laid off because they were replaced by automation. Testers, were, however laid off because they were among a group who:
a) had little or no coding skills
b) had no potential to learn those skills
c) weren't very good testers either
There's a difference, as you know, between button pushers and testers. MS laid off button pushers.
Anonymous because I've probably said too much.
3:41 AM, August 11, 2006
這和我昨天聽到的基調大致相同, Microsoft認為tester要能做manual testing, 也要能做 automatic testing, 不能只是會其中一樣. 所以藉由這樣的理由, 一方面把一些舊的tester轉型, 或是lay off掉, 以提升tester整體的能力.
不過他也再三強調人還是最重要的, 這和這篇文章的作者觀點是一致的. 若是人無法思考, 快速應變, 你有再多automation或是tool, 還是無法解決問題的.
--------------------------------------------------------------
Shrini Kulkarni said...
Thanks anonymous for clarifying about firing of button pushers.
I am not sure about designations of those - were they SDETs or STEs?
Going by what you explained it appears that they were laid off for performance reasons.
I am surprised as why Microsoft did not do a good PR work at clarifying this? Can you point to any official clarification this - article, blog post or some thing like that?
Some statements/views mentioned in the quoted news post point to a story that seem to justify layoff and link them with automation/cost cutting
1. spokeswoman Tami Begasse said there is no correlation between the tester layoffs and the company's growing use of workers abroad. She said the group was restructured because it's automating some testing tasks.
2. In September, the server group said it was cutting 93 positions as part of its move toward automated testing.
3. One factor is the push by executives to cut costs and adjust to the slower growth in the technology industry.
4. The 62 work in the core operating system division, headed by Brian Valentine, a senior vice president. In the past, Valentine has called on managers to consider outsourcing work to India as a way to get more done for less cost.
other thing I would like to know is - will you fire a tester for not having skills for coding?
Having gone through microsoft interview process (at india) - I know that mediocre tester can not make it to Microsoft Job. No coding skills, no aptitude or potential for learning and no good testing skills - Did MS make those 62 hiring mistakes and attempted to correct by firing them at once?
I would encourage you to me write to me to discuss more about this...
Shrini
11:01 AM, August 11, 2006
====================================
這裡是那篇Seattle times新聞的全文
Microsoft lays off 62 testers
By Brier Dudley
Seattle Times technology reporter
Microsoft is laying off 62 test engineers in the second round of cuts hitting Windows testers in the past five months.
The company has recently sent test work overseas, but a spokeswoman denied that's a factor. She said automation, not globalization, led to the cuts.
Microsoft notified the employees Tuesday and Wednesday last week, and the layoffs took effect Friday. The testers were given the option of staying, with pay, for six weeks while they look for other jobs in the company.
But finding other test jobs in the company may be a challenge.
The 62 work in the core operating system division, headed by Brian Valentine, a senior vice president. In the past, Valentine has called on managers to consider outsourcing work to India as a way to get more done for less cost.
Microsoft is outsourcing some test work to overseas companies such as Wipro, Infosys and Tata Consultancy in India. It's also expanding its overseas research and development facilities with a new campus opening this month in Hyderabad, India.
But spokeswoman Tami Begasse said there is no correlation between the tester layoffs and the company's growing use of workers abroad. She said the group was restructured because it's automating some testing tasks.
"It's not outsourcing related, offshoring related," she said. "It's simply they no longer meet the needs of this position."
The company initially told employees that 64 people were being laid off, but the number was later reduced to 62.
In September, the server group said it was cutting 93 positions as part of its move toward automated testing.
Separately, the company in August announced that it was laying off 76 employees in its Xbox division.
Layoffs used to be a rarity at Microsoft, but the company has become more aggressive about pruning its ranks. One factor is the push by executives to cut costs and adjust to the slower growth in the technology industry.
The Windows division has also embraced automated testing systems, including tools developed by the company's research group to check for software bugs.
Begasse said the move to automate some testing ultimately benefits customers.
"These changes are designed to improve the quality of our products and efficiencies in delivering them to customers, so the realignment demonstrates commitment to improving test-engineer efficiencies within that group," she said.
最近我們和Microsoft有密切的合作, 最主要是想增進我們公司整體軟體開發的能力. 在昨天的會議中, 提到了Microsoft對QA人員的策略, 它讓我想到之前看過的一篇文章. 第一次瞄到時, 還不是很注意. 現在看起來, Microsoft很早就打定這樣的主意.
Test Automation - Takes toll of Microsoft Testers ....
http://shrinik.blogspot.com/2006/08/test-automation-takes-toll-of.html
這篇blog文是在2006年寫的, 作者(他以前也是微軟員工)說他看到Seattle times在 2004 Jan報導, 提到Microsoft lay off了Windows group 中62個testers
http://seattletimes.nwsource.com/html/microsoft/2002155249_mslayoffs20.html
報導中寫著, lay off的原因如下
1. They had automation so testers not required.
2. They need to cut cost - either send jobs to India (low cost option) or aggressively automate...
作者第一時間覺得很可悲, Microsoft居然走到這地步, 居然相信automation可以取代人腦. 不過因為沒有任何官方回應, 或是內部小道消息. 作者也無法確認Microsoft真正的目的為何. 因此作者post這篇文章, 希望內部知情人士能透露一二.
於是就有一些人回應如下:
====================================
Anonymous said...
No testers were laid off because they were replaced by automation. Testers, were, however laid off because they were among a group who:
a) had little or no coding skills
b) had no potential to learn those skills
c) weren't very good testers either
There's a difference, as you know, between button pushers and testers. MS laid off button pushers.
Anonymous because I've probably said too much.
3:41 AM, August 11, 2006
這和我昨天聽到的基調大致相同, Microsoft認為tester要能做manual testing, 也要能做 automatic testing, 不能只是會其中一樣. 所以藉由這樣的理由, 一方面把一些舊的tester轉型, 或是lay off掉, 以提升tester整體的能力.
不過他也再三強調人還是最重要的, 這和這篇文章的作者觀點是一致的. 若是人無法思考, 快速應變, 你有再多automation或是tool, 還是無法解決問題的.
--------------------------------------------------------------
Shrini Kulkarni said...
Thanks anonymous for clarifying about firing of button pushers.
I am not sure about designations of those - were they SDETs or STEs?
Going by what you explained it appears that they were laid off for performance reasons.
I am surprised as why Microsoft did not do a good PR work at clarifying this? Can you point to any official clarification this - article, blog post or some thing like that?
Some statements/views mentioned in the quoted news post point to a story that seem to justify layoff and link them with automation/cost cutting
1. spokeswoman Tami Begasse said there is no correlation between the tester layoffs and the company's growing use of workers abroad. She said the group was restructured because it's automating some testing tasks.
2. In September, the server group said it was cutting 93 positions as part of its move toward automated testing.
3. One factor is the push by executives to cut costs and adjust to the slower growth in the technology industry.
4. The 62 work in the core operating system division, headed by Brian Valentine, a senior vice president. In the past, Valentine has called on managers to consider outsourcing work to India as a way to get more done for less cost.
other thing I would like to know is - will you fire a tester for not having skills for coding?
Having gone through microsoft interview process (at india) - I know that mediocre tester can not make it to Microsoft Job. No coding skills, no aptitude or potential for learning and no good testing skills - Did MS make those 62 hiring mistakes and attempted to correct by firing them at once?
I would encourage you to me write to me to discuss more about this...
Shrini
11:01 AM, August 11, 2006
====================================
這裡是那篇Seattle times新聞的全文
Microsoft lays off 62 testers
By Brier Dudley
Seattle Times technology reporter
Microsoft is laying off 62 test engineers in the second round of cuts hitting Windows testers in the past five months.
The company has recently sent test work overseas, but a spokeswoman denied that's a factor. She said automation, not globalization, led to the cuts.
Microsoft notified the employees Tuesday and Wednesday last week, and the layoffs took effect Friday. The testers were given the option of staying, with pay, for six weeks while they look for other jobs in the company.
But finding other test jobs in the company may be a challenge.
The 62 work in the core operating system division, headed by Brian Valentine, a senior vice president. In the past, Valentine has called on managers to consider outsourcing work to India as a way to get more done for less cost.
Microsoft is outsourcing some test work to overseas companies such as Wipro, Infosys and Tata Consultancy in India. It's also expanding its overseas research and development facilities with a new campus opening this month in Hyderabad, India.
But spokeswoman Tami Begasse said there is no correlation between the tester layoffs and the company's growing use of workers abroad. She said the group was restructured because it's automating some testing tasks.
"It's not outsourcing related, offshoring related," she said. "It's simply they no longer meet the needs of this position."
The company initially told employees that 64 people were being laid off, but the number was later reduced to 62.
In September, the server group said it was cutting 93 positions as part of its move toward automated testing.
Separately, the company in August announced that it was laying off 76 employees in its Xbox division.
Layoffs used to be a rarity at Microsoft, but the company has become more aggressive about pruning its ranks. One factor is the push by executives to cut costs and adjust to the slower growth in the technology industry.
The Windows division has also embraced automated testing systems, including tools developed by the company's research group to check for software bugs.
Begasse said the move to automate some testing ultimately benefits customers.
"These changes are designed to improve the quality of our products and efficiencies in delivering them to customers, so the realignment demonstrates commitment to improving test-engineer efficiencies within that group," she said.
- Dec 17 Wed 2008 09:58
讓QA還會繼續想做QA
讓QA還會繼續想做QA
keeping testers in test
http://blogs.msdn.com/james_whittaker/archive/2008/11/20/keeping-testers-in-test.aspx
這個問題, 我想是大多數公司或是QA manager的夢靨. 一方面找不到好人才, 一方面人才也不易留住. 很容易地, QA不是離職就是換跑道到RD去. 讓我們來看看Microsoft資深的QA manager如何看待這個問題.
在某一場合, 作者被問到一個問題: 你如何保持在QA這條路上, 而不會想轉換到RD去呢?
他說他已經聽過很多次這樣的問題. 許多人把QA視為是RD的一個跳板, 一個先期訓練中心. 他說如果是這樣也不錯, 因為那將會有許多RD知道QA在做什麼, 會比較注重品質, 也會比較容易和QA溝通.
作者也認為並不是因為RD要寫code, 所以QA想過去. 其實QA自己也是需要寫code, 去做automation或是幫助測試更方面. 他認為QA會想離開是因為太多QA manager無法求新, 只考慮shipment和 schedule, 缺乏有求新求變的環境和心態.
而至於願意留下來的QA, 則是因為在team裡面, 他們有機會去做invent, investigate and discover, 使得他們有成就感.
所以如何讓你的QA願意留下來呢? 讓他們有機會去創新. 如果他們都只是focus 在test cases execution和ship schedule, 那大家都會想跑的
以下是一些讀者的回應
===============================
calkelpdiver said:
他提到QA會想換工作的原因
(1) lack of credibility & respect, lack of pay, lack of support, insane work schedules, finger pointing
(2) getting the opportunity to do new and innovate things in this line of work doesn't come often for the average tester in the average company (Microsoft, and other large shops may be different).
(3) Want to earn more money (RD's pay is higher)
===============================
swn1 said:
他提出一個可能的改善方法: rotation
Assign testers to development teams, assign developers to test rotations.
Developers became very conscious of the need for documentable designs, meaningful messages, and such. And customers were shocked to have the phone answered by someone who understood and could actually fix their problem. Good for everyone.
===============================
ru_altom said:
他認為rotation不太可行, 原因如下
(1) 你需要假設RD是一個好的QA, QA 也是一個好的RD
(2) RD 和QA的mindset不同, A tester will write code to break someone else's code, while a developer will aim to write unbreakable code.
所以他贊同JW的作法:
Innovation is the best way to keep your testers (and developers as well) content and at their best. Give them a chance to invent, to find new ways, to try their ideas - and they won't leave, not for another department and not for another company.
keeping testers in test
http://blogs.msdn.com/james_whittaker/archive/2008/11/20/keeping-testers-in-test.aspx
這個問題, 我想是大多數公司或是QA manager的夢靨. 一方面找不到好人才, 一方面人才也不易留住. 很容易地, QA不是離職就是換跑道到RD去. 讓我們來看看Microsoft資深的QA manager如何看待這個問題.
在某一場合, 作者被問到一個問題: 你如何保持在QA這條路上, 而不會想轉換到RD去呢?
他說他已經聽過很多次這樣的問題. 許多人把QA視為是RD的一個跳板, 一個先期訓練中心. 他說如果是這樣也不錯, 因為那將會有許多RD知道QA在做什麼, 會比較注重品質, 也會比較容易和QA溝通.
作者也認為並不是因為RD要寫code, 所以QA想過去. 其實QA自己也是需要寫code, 去做automation或是幫助測試更方面. 他認為QA會想離開是因為太多QA manager無法求新, 只考慮shipment和 schedule, 缺乏有求新求變的環境和心態.
而至於願意留下來的QA, 則是因為在team裡面, 他們有機會去做invent, investigate and discover, 使得他們有成就感.
所以如何讓你的QA願意留下來呢? 讓他們有機會去創新. 如果他們都只是focus 在test cases execution和ship schedule, 那大家都會想跑的
以下是一些讀者的回應
===============================
calkelpdiver said:
他提到QA會想換工作的原因
(1) lack of credibility & respect, lack of pay, lack of support, insane work schedules, finger pointing
(2) getting the opportunity to do new and innovate things in this line of work doesn't come often for the average tester in the average company (Microsoft, and other large shops may be different).
(3) Want to earn more money (RD's pay is higher)
===============================
swn1 said:
他提出一個可能的改善方法: rotation
Assign testers to development teams, assign developers to test rotations.
Developers became very conscious of the need for documentable designs, meaningful messages, and such. And customers were shocked to have the phone answered by someone who understood and could actually fix their problem. Good for everyone.
===============================
ru_altom said:
他認為rotation不太可行, 原因如下
(1) 你需要假設RD是一個好的QA, QA 也是一個好的RD
(2) RD 和QA的mindset不同, A tester will write code to break someone else's code, while a developer will aim to write unbreakable code.
所以他贊同JW的作法:
Innovation is the best way to keep your testers (and developers as well) content and at their best. Give them a chance to invent, to find new ways, to try their ideas - and they won't leave, not for another department and not for another company.
- Dec 12 Fri 2008 09:17
在面試QA時, 50 個常問的問題
在面試QA時, 50 個常問的問題
Top 50 Software Testing/SQA FAQs you may be asked in an interview
http://software-testing-zone.blogspot.com/2007/01/top-50-sofware-testingsqa-faqs-you-may.html
在面試QA時, 你會苦於不知道要問什麼問題, 來確認是否有testing的經驗嗎? 這裡作者提供了50個Q & A, 讓你可以徹底了解candidate會些什麼. 雖然答案部分我不是很滿意, 但是還是可以參考一下.
當然這些問題, 不只在interview時可以問, 你也可以以試卷的方式, 來檢驗candidate的程度.
不過這好像只能問問QA lead 或QA manager, 在台灣基本上是不容易適用. 因為台灣軟體業重視品質的程度, 是乎還有待改進. 從公共工程的品質, 應該可略窺一二.
Top 50 Software Testing/SQA FAQs you may be asked in an interview
http://software-testing-zone.blogspot.com/2007/01/top-50-sofware-testingsqa-faqs-you-may.html
在面試QA時, 你會苦於不知道要問什麼問題, 來確認是否有testing的經驗嗎? 這裡作者提供了50個Q & A, 讓你可以徹底了解candidate會些什麼. 雖然答案部分我不是很滿意, 但是還是可以參考一下.
當然這些問題, 不只在interview時可以問, 你也可以以試卷的方式, 來檢驗candidate的程度.
不過這好像只能問問QA lead 或QA manager, 在台灣基本上是不容易適用. 因為台灣軟體業重視品質的程度, 是乎還有待改進. 從公共工程的品質, 應該可略窺一二.
- Dec 04 Thu 2008 09:41
什麼時候測試可以停止?
什麼時候測試可以停止?
什麼時候已經測夠了, 可以停止了, 這個問題是QA常常會被問到的, 也是其中一個不容易回答的問題. 可是這也是你無法逃避的問題, 因為每次product 要release時, 你就要面對一次, 即使沒有人問你, 你自己也會問自己是不是可以出貨了.
以下是常見的的criteria
1. All the high priority bugs are fixed.
- 這通常是最重要的, 如果重要的bug沒解, 是不敢出貨的
- 不過通常僅限於重要的bug, 至於所有bug都要解掉這件事, 好像不是每個人都願意買單的. 所以這裡會有些落差存在, 需要事先和manager and RD溝通, 否則最後會沒有共識.
2. The rate at which bugs are found is too small.
- 通常這是要看是否bug submission ratio是否下降, 也就是看是否有收斂的跡象. 如果還是在向上發展, 當然是無法結束.
- 即使現在bug已經解完, 並且目前沒有發現新bug, 但是若是目前submission ratio值是很高, 也不可能瞬間忽然降成0. 所以這通常意味著, 其實受測系統裡面還有很多潛藏的bug, 只是目前還沒被抓出來. 所以還是要降低到某個程度才是比較save的狀況.
3. The testing budget is exhausted.
沒錢自然就沒什麼好說的, 當然就停止測試啦!!
4. The project duration is completed.
時間了也是個無可奈何的指標, 這有可能時當初schedule就有問題, 或是測試規劃的有問題. 導致時間不夠使用.
5. The risk in the project is under acceptable limit.
如果risk很低, 是project可以接受的範圍當然是無所謂啦!! Manager說了算!! 呵呵~~~
其實測試是否可以停止,是否足夠, 這要看你是否收及足夠的information. 畢竟測試是個information-gethering的流程, 如果你有足夠的資訊, 讓你可以掌握目前project品質的狀態, 你自然可以很清楚知道目前測試是否已經夠了, 可以結束了.
所以當你不知道是否測試可以結束時, 先問問自己你是否掌握專案的狀況. 如果不知道, 當然是回答不了啦!!
Reference
1. When should Testing stop?
http://creativetesters678.blogspot.com/2008/07/when-should-testing-stop.html
2. Chapter 8 Manaing the Testing Project, Lesson Learned in Software Testing.
Lesson 185 "Enough testing" mean "enough informaiton for my clients to make good decisions"
什麼時候已經測夠了, 可以停止了, 這個問題是QA常常會被問到的, 也是其中一個不容易回答的問題. 可是這也是你無法逃避的問題, 因為每次product 要release時, 你就要面對一次, 即使沒有人問你, 你自己也會問自己是不是可以出貨了.
以下是常見的的criteria
1. All the high priority bugs are fixed.
- 這通常是最重要的, 如果重要的bug沒解, 是不敢出貨的
- 不過通常僅限於重要的bug, 至於所有bug都要解掉這件事, 好像不是每個人都願意買單的. 所以這裡會有些落差存在, 需要事先和manager and RD溝通, 否則最後會沒有共識.
2. The rate at which bugs are found is too small.
- 通常這是要看是否bug submission ratio是否下降, 也就是看是否有收斂的跡象. 如果還是在向上發展, 當然是無法結束.
- 即使現在bug已經解完, 並且目前沒有發現新bug, 但是若是目前submission ratio值是很高, 也不可能瞬間忽然降成0. 所以這通常意味著, 其實受測系統裡面還有很多潛藏的bug, 只是目前還沒被抓出來. 所以還是要降低到某個程度才是比較save的狀況.
3. The testing budget is exhausted.
沒錢自然就沒什麼好說的, 當然就停止測試啦!!
4. The project duration is completed.
時間了也是個無可奈何的指標, 這有可能時當初schedule就有問題, 或是測試規劃的有問題. 導致時間不夠使用.
5. The risk in the project is under acceptable limit.
如果risk很低, 是project可以接受的範圍當然是無所謂啦!! Manager說了算!! 呵呵~~~
其實測試是否可以停止,是否足夠, 這要看你是否收及足夠的information. 畢竟測試是個information-gethering的流程, 如果你有足夠的資訊, 讓你可以掌握目前project品質的狀態, 你自然可以很清楚知道目前測試是否已經夠了, 可以結束了.
所以當你不知道是否測試可以結束時, 先問問自己你是否掌握專案的狀況. 如果不知道, 當然是回答不了啦!!
Reference
1. When should Testing stop?
http://creativetesters678.blogspot.com/2008/07/when-should-testing-stop.html
2. Chapter 8 Manaing the Testing Project, Lesson Learned in Software Testing.
Lesson 185 "Enough testing" mean "enough informaiton for my clients to make good decisions"
- Nov 22 Sat 2008 21:44
QA的薪水到底有多少
QA的薪水到底有多少
http://www.itjobswatch.co.uk/jobs/uk/software%20testing.do
最近在網路上看到一個QA job的survey, 它對QA的需求, 新水以及所需的技能, 作了詳細調查. 雖然它是UK的網站, 但是應該還是有一定參考價值
http://www.itjobswatch.co.uk/jobs/uk/software%20testing.do
最近在網路上看到一個QA job的survey, 它對QA的需求, 新水以及所需的技能, 作了詳細調查. 雖然它是UK的網站, 但是應該還是有一定參考價值
- Oct 21 Tue 2008 13:56
Why counting is a bad idea
Why counting is a bad idea
by Shrini Kulkarni
http://shrinik.blogspot.com/2006/12/why-counting-is-bad-idea.html
通常Test Manager會利用下面index, 來評量QA是否做的很好
No of Test cases prepared: 1230
- Oct 13 Mon 2008 22:59
如何評量是否是一個好的QA
如何評量是否是一個好的QA
measuring testers
http://blogs.msdn.com/james_whittaker/archive/2008/07/22/measuring-testers.aspx
一個好的QA在於他的心態(mindset)是否正確, 但是心態這種東西是很難加以衡量的. 因此很多manager都是以數字來衡量績效好不好. 像是bug數, test case數, 或是有多少被automate.
可是我想數字這東西常常會造成一些副作用, 因為你只會看到數字, 而不會去想他背後的涵義, 或者是要因應目前狀況做去適當的調整.
所以作者認為與其考慮數字, 不如考慮下面事情
- Sep 24 Wed 2008 12:58
有關test management 相關的書籍
有關test management 相關的書籍
目前最有名的是這兩本書, Rex Blacky在這方面真的十分有經驗, 他可以寫一堆想都想不到的東西, 你不得不佩服他經驗真的是很豐富. 我想若是有志成為QA manager的人, 這兩本是一定要看的
1. Critical Testing Processes: Plan, Prepare, Perform, Perfect
by Rex Black
http://www.amazon.com/Critical-Testing-Processes-Prepare-Perform/dp/0201748681/ref=pd_sim_b_2
2. Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing
- Jul 15 Tue 2008 18:22
什麼是QA 經理要做的事
最近公司在討論QA manager到底要做些什麼？有哪些挑戰是我們目前大家所共同遭遇的？一開始大家討論就很熱烈，但是很快地，答案就收斂下來，因為大家的心中的痛都一樣。
首先，在工作項目方面我們認為QA manager有以下項目：
1. 人員的管理：包含指導(coach)、發展(develop)、生涯規劃(career planning)等等。
2. 人員的錄用(Hiring)與解雇(firing)
3. 和公司目標(objective)對齊(alignment)
首先，在工作項目方面我們認為QA manager有以下項目：
1. 人員的管理：包含指導(coach)、發展(develop)、生涯規劃(career planning)等等。
2. 人員的錄用(Hiring)與解雇(firing)
3. 和公司目標(objective)對齊(alignment)
