Before this July and next self-dealing system, i 'd like to learn anything of RFT......
四处找的文章之Elfriede Dustin
上一篇 / 下一篇 2007-04-26 09:03:23 / 个人分类：混沌初期
（说明，现在处于“读”的时期，我想要多看看，看到一个怎样的程度呢？反过来知道是怎么回事，正过来还是知道是怎么回事！话不多说，就从今天开始，在这个小小的空间，记录下我所看过的网页内容或链接，留下足迹，遇到好风景，以后还可以再去看看～看到一个怎样的程度呢？～反过来觉得好，正过来还是觉得好）
Elfriede Dustin is author of various books on testing - "Automated Software Testing," "Quality Web Systems," and her latest book "Effective Software Testing."
Her website www.effectivesoftwaretesting.com was created to create a community of software professionals in the Washington DC area.
If you want to ask her more questions or you want to send any feedback on this interview, please send it to webmaster @ whatistesting.com
Q1. Elfriede please tell us something about yourself, your interests and things that you do in your free time.
Originally I am from Germany where I’ve received my business degree and then went on to get a Computer Science degree at KSU. In 1984 at one of my first jobs working at a US Government law center, we received a number of Wang computers and I lead the automation of the claims processes. Ever since then I have been hooked on computers, automation, and testing. Having lived in the suburbs of Washington, DC over a decade, I am now a naturalized American citizen. I enjoy spending any of my free time getting smarter in my chosen field of testing. Additionally, I enjoy spending time with my two daughters Jackie and Erika.
Q2. What prompted you to write the books that you wrote? What kind of response do you think these books have received?
In 1997 at a Rational users conference I presented the topic "Introducing Automated Testing to your Project." After the presentation I received uncountable repetitive inquiries from numerous sources throughout the world (even Belgium) about this same topic. It made me realize that there is a need for a book to put out this information and it prompted me to write the book "Automated Software Testing," together with my co-authors and former co-workers Jeff Rashka and John Paul. The books have been very well received, for example the book "Automated Software Testing" is in its 9th printing and has been translated into German, Russian, Japanese, Chinese, and is also available as a less expensive version for the testing audience in India.
Q3. What were your sources of experience that your book "Effective Software Testing" drew on?
"Effective Software Testing" is based on my many years of testing experience combined with the many years of software development experience of my former co-worker Douglas McDiarmid. The book also draws on the experiences of my former co-workers and co-authors Jeff Rashka, Program Manager, and John Paul, Developer and now CEO, as it also draws on the content of our books "Automated Software Testing" and "Quality Web Systems.”
Q4. Are you working on any other book?
I am in the process of writing a book on Security Testing for QA professionals, published by Symantec Press, written with two Symantec security experts. I feel there is a need for such a book that's specifically geared towards the testing and QA professionals. Not enough is known about how to approach security testing as a QA professional, often it's just a band-aid and too late in the development life-cycle.
My latest article Teamwork Tackles the Quality Goal was written for Software Test and Performance magazine, see www.stpmag.com for a free download. A summary of one of my five “Software Test and Performance conference” (see www.stpcon.com) presentations “Introducing Automated Software Testing” recently appeared in the SDMagazine newsletter. I am also preparing for a presentation at the ICSTest (see www.icstest.com) conference in Duesseldorf, Germany in April, while working full-time as an employee, i.e. an internal SQA consultant to GSS, Symantec. (Please note all opinions expressed here are my own and not those of my employer.)
Q5. Do you think there is a gap between what testing consultants and trainers teach and what the testers and test managers in the trenches face in their daily work? In what ways?
Yes, I definitely see a gap in what testing consultants and trainers teach and what testers and test managers face in the trenches. Theories are nice to have, but some theories are just not realistic and too time consuming or expensive to implement. In the trenches we constantly face ever shrinking budgets and schedules, and go-live dates and production deadlines which can’t be moved, and often the development schedule slips and cuts into the testing time.
In the trenches, so much depends on the developers’ skills. The most efficient and knowledgeable testers cannot succeed if developers implement bad software and/or ineffective software development life-cycles and processes are in place. If testing is the only quality phase implemented as part of a QA realm, it can at most be considered a band-aid often too late in the system development lifecycle to make much of a quality difference. Testing is only one piece of the Quality puzzle.
I don't see this here at Symantec, but I have seen it at other companies where there is still this general confusion by some management about what testers do. The one side of the management camp thinks that “anyone” can do the testing and no special skills are required and the other side of the management camp expects testers to “test quality into a system” and blames the tester if a defect makes it into production. When it comes to testing salaries and job requirements, generally a tester is paid less and technically less is expected of him. Generally there is still a gap between testers’ technical knowledge vs. the developer technical knowledge. This gap also rears itself in still little or no respect for the tester profession and testing still often being seen as the underdog and necessary evil. Based on this general mindset, I wrote my article Teamwork Tackles the Quality Goal on “integrating the “independent” testing team where I make the point that the tester has to be every bit as technical as the developer, working integrated with the development team, while maintaining the independent testing frame of mind. The testing profession has so much to offer, but so little about how it can really effectively be implemented is known or used.
Q6. Who in the testing community has influenced your thinking most? Actually, my Computer Science professor Dr. Gustafson at Kansas State University has influenced my thinking about testing and quality in general. I took his graduate level course on "Quality software engineering processes" which peaked my interest in Quality and testing and I learned about great quality concepts and influential thinkers such as Tom DeMarco, Capers Jones, Boris Beizer, and Gerald Weinberg.
Q7. According to you what are top three things that one should learn/practice/be good at to be an effective and efficient software tester?
To be an efficient software tester the person really has to enjoy testing, have a knack for it, be analytical, detail oriented, and be versatile, such as a) be technically savvy, b) understand the business, and c) never stop learning and improving on the testing efforts
Q8. What do you think is the current state of automation? Where do you see automation heading towards? Do you think a paradigm shift is required in order to have more automation? Do you think there are other areas where tool vendors need to focus in addition to what they focus on right now?
Current state of automation. During a recent presentation at the Software Test and Performance conference (www.stpcon.com) I surveyed and learned that 50 percent of my audience had test automation tools that have become "shelf-ware." Those people are now tasked with resurrecting the automation tools and efforts, which can be an exercise in futility for many reasons. They will have to keep in mind whether the tool is still compatible with the technology being used, i.e. has the technology changed since the tool was purchased. Also, if the automation didn't succeed in the first go around did they note the reason for failure and have those "lessons learned" been evaluated so they wouldn't be repeated on the second automation attempt, etc.
This inofficial survey result is just another example that shows not much progress is being made with the use of vendor provided automated testing tools, an issue we've already discussed in our book "Automated Software Testing" published in 1999, "When inefficient automated testing implementation hasn't shown significant ROI, and budget pressures materialize, planned expenditures for test tool licenses and related tool support may be scratched. Often the tools end up as shelf-ware."
Q9. Where do you see automation heading towards? Granted vendor provided tools continue to improve, vendors still have and will continue to have a difficult time to keep up with all the latest and greatest technologies and third party controls and widgets, which are usually the source for the biggest compatibility issues and user frustrations. People will continue to struggle with the vendor provided tools, others will turn to in-house developed automation efforts or to automation freeware. Here are some important tips before "jumping on the test automation bandwagon."
• Know the types of tools available along with the problem they are trying to solve. There is no one best tool on the market.
• Safeguard the integrity of the automated test scrīpts by using a configuration management tool to baseline them.
• Consider that automated testing is software development.
• Educate stakeholders about the test automation efforts, especially developers who need to understand the impact any code changes could have on it.
• Manage the expectations by not overselling test automation's return on investment.
• Do not let automated testing become a "side activity" to work on when time allows; ideally use technical testing talent whose sole focus is on test automation.
• Not all testers need to be "automators," since development expertise is required.
• Decide whether to buy or build a tool or whether to use freeware (or all of the above)
Q10. Do you think a paradigm shift is required in order to have more automation? Unit test automation is the most effective defect detection/test automation technique. Too many companies still focus all of their test automation efforts on system testing without realizing that unit test automation can have the most ROI. Wishful thinking: Wouldn't it be nice if self-testable development languages existed, such as components are developed automated related unit tests were automatically self-generated.
Q11. In absence of licenses most people can’t learn using tools from most of the tool vendors. But employers generally want tools knowledge. How do you think testers can break this vicious circle and gain automation knowledge?
I think employers need to be educated to understand that someone with a development background can easily pick up any automated testing tool, no matter which one. When I hire automated testers and they can show extensive experience in one tool's scrīpting language or any scrīpting language for that matter, chances are they will be able to pick up and learn another tool's scrīpting language. Testers need to remember that automation is software development, and it is important to have experience in one or more programming or scrīpting languages.
文章来源于http://www.whatistesting.com/interviews/edustin.htm
Elfriede Dustin is author of various books on testing - "Automated Software Testing," "Quality Web Systems," and her latest book "Effective Software Testing."
Her website www.effectivesoftwaretesting.com was created to create a community of software professionals in the Washington DC area.
If you want to ask her more questions or you want to send any feedback on this interview, please send it to webmaster @ whatistesting.com
Q1. Elfriede please tell us something about yourself, your interests and things that you do in your free time.
Originally I am from Germany where I’ve received my business degree and then went on to get a Computer Science degree at KSU. In 1984 at one of my first jobs working at a US Government law center, we received a number of Wang computers and I lead the automation of the claims processes. Ever since then I have been hooked on computers, automation, and testing. Having lived in the suburbs of Washington, DC over a decade, I am now a naturalized American citizen. I enjoy spending any of my free time getting smarter in my chosen field of testing. Additionally, I enjoy spending time with my two daughters Jackie and Erika.
Q2. What prompted you to write the books that you wrote? What kind of response do you think these books have received?
In 1997 at a Rational users conference I presented the topic "Introducing Automated Testing to your Project." After the presentation I received uncountable repetitive inquiries from numerous sources throughout the world (even Belgium) about this same topic. It made me realize that there is a need for a book to put out this information and it prompted me to write the book "Automated Software Testing," together with my co-authors and former co-workers Jeff Rashka and John Paul. The books have been very well received, for example the book "Automated Software Testing" is in its 9th printing and has been translated into German, Russian, Japanese, Chinese, and is also available as a less expensive version for the testing audience in India.
Q3. What were your sources of experience that your book "Effective Software Testing" drew on?
"Effective Software Testing" is based on my many years of testing experience combined with the many years of software development experience of my former co-worker Douglas McDiarmid. The book also draws on the experiences of my former co-workers and co-authors Jeff Rashka, Program Manager, and John Paul, Developer and now CEO, as it also draws on the content of our books "Automated Software Testing" and "Quality Web Systems.”
Q4. Are you working on any other book?
I am in the process of writing a book on Security Testing for QA professionals, published by Symantec Press, written with two Symantec security experts. I feel there is a need for such a book that's specifically geared towards the testing and QA professionals. Not enough is known about how to approach security testing as a QA professional, often it's just a band-aid and too late in the development life-cycle.
My latest article Teamwork Tackles the Quality Goal was written for Software Test and Performance magazine, see www.stpmag.com for a free download. A summary of one of my five “Software Test and Performance conference” (see www.stpcon.com) presentations “Introducing Automated Software Testing” recently appeared in the SDMagazine newsletter. I am also preparing for a presentation at the ICSTest (see www.icstest.com) conference in Duesseldorf, Germany in April, while working full-time as an employee, i.e. an internal SQA consultant to GSS, Symantec. (Please note all opinions expressed here are my own and not those of my employer.)
Q5. Do you think there is a gap between what testing consultants and trainers teach and what the testers and test managers in the trenches face in their daily work? In what ways?
Yes, I definitely see a gap in what testing consultants and trainers teach and what testers and test managers face in the trenches. Theories are nice to have, but some theories are just not realistic and too time consuming or expensive to implement. In the trenches we constantly face ever shrinking budgets and schedules, and go-live dates and production deadlines which can’t be moved, and often the development schedule slips and cuts into the testing time.
In the trenches, so much depends on the developers’ skills. The most efficient and knowledgeable testers cannot succeed if developers implement bad software and/or ineffective software development life-cycles and processes are in place. If testing is the only quality phase implemented as part of a QA realm, it can at most be considered a band-aid often too late in the system development lifecycle to make much of a quality difference. Testing is only one piece of the Quality puzzle.
I don't see this here at Symantec, but I have seen it at other companies where there is still this general confusion by some management about what testers do. The one side of the management camp thinks that “anyone” can do the testing and no special skills are required and the other side of the management camp expects testers to “test quality into a system” and blames the tester if a defect makes it into production. When it comes to testing salaries and job requirements, generally a tester is paid less and technically less is expected of him. Generally there is still a gap between testers’ technical knowledge vs. the developer technical knowledge. This gap also rears itself in still little or no respect for the tester profession and testing still often being seen as the underdog and necessary evil. Based on this general mindset, I wrote my article Teamwork Tackles the Quality Goal on “integrating the “independent” testing team where I make the point that the tester has to be every bit as technical as the developer, working integrated with the development team, while maintaining the independent testing frame of mind. The testing profession has so much to offer, but so little about how it can really effectively be implemented is known or used.
Q6. Who in the testing community has influenced your thinking most? Actually, my Computer Science professor Dr. Gustafson at Kansas State University has influenced my thinking about testing and quality in general. I took his graduate level course on "Quality software engineering processes" which peaked my interest in Quality and testing and I learned about great quality concepts and influential thinkers such as Tom DeMarco, Capers Jones, Boris Beizer, and Gerald Weinberg.
Q7. According to you what are top three things that one should learn/practice/be good at to be an effective and efficient software tester?
To be an efficient software tester the person really has to enjoy testing, have a knack for it, be analytical, detail oriented, and be versatile, such as a) be technically savvy, b) understand the business, and c) never stop learning and improving on the testing efforts
Q8. What do you think is the current state of automation? Where do you see automation heading towards? Do you think a paradigm shift is required in order to have more automation? Do you think there are other areas where tool vendors need to focus in addition to what they focus on right now?
Current state of automation. During a recent presentation at the Software Test and Performance conference (www.stpcon.com) I surveyed and learned that 50 percent of my audience had test automation tools that have become "shelf-ware." Those people are now tasked with resurrecting the automation tools and efforts, which can be an exercise in futility for many reasons. They will have to keep in mind whether the tool is still compatible with the technology being used, i.e. has the technology changed since the tool was purchased. Also, if the automation didn't succeed in the first go around did they note the reason for failure and have those "lessons learned" been evaluated so they wouldn't be repeated on the second automation attempt, etc.
This inofficial survey result is just another example that shows not much progress is being made with the use of vendor provided automated testing tools, an issue we've already discussed in our book "Automated Software Testing" published in 1999, "When inefficient automated testing implementation hasn't shown significant ROI, and budget pressures materialize, planned expenditures for test tool licenses and related tool support may be scratched. Often the tools end up as shelf-ware."
Q9. Where do you see automation heading towards? Granted vendor provided tools continue to improve, vendors still have and will continue to have a difficult time to keep up with all the latest and greatest technologies and third party controls and widgets, which are usually the source for the biggest compatibility issues and user frustrations. People will continue to struggle with the vendor provided tools, others will turn to in-house developed automation efforts or to automation freeware. Here are some important tips before "jumping on the test automation bandwagon."
• Know the types of tools available along with the problem they are trying to solve. There is no one best tool on the market.
• Safeguard the integrity of the automated test scrīpts by using a configuration management tool to baseline them.
• Consider that automated testing is software development.
• Educate stakeholders about the test automation efforts, especially developers who need to understand the impact any code changes could have on it.
• Manage the expectations by not overselling test automation's return on investment.
• Do not let automated testing become a "side activity" to work on when time allows; ideally use technical testing talent whose sole focus is on test automation.
• Not all testers need to be "automators," since development expertise is required.
• Decide whether to buy or build a tool or whether to use freeware (or all of the above)
Q10. Do you think a paradigm shift is required in order to have more automation? Unit test automation is the most effective defect detection/test automation technique. Too many companies still focus all of their test automation efforts on system testing without realizing that unit test automation can have the most ROI. Wishful thinking: Wouldn't it be nice if self-testable development languages existed, such as components are developed automated related unit tests were automatically self-generated.
Q11. In absence of licenses most people can’t learn using tools from most of the tool vendors. But employers generally want tools knowledge. How do you think testers can break this vicious circle and gain automation knowledge?
I think employers need to be educated to understand that someone with a development background can easily pick up any automated testing tool, no matter which one. When I hire automated testers and they can show extensive experience in one tool's scrīpting language or any scrīpting language for that matter, chances are they will be able to pick up and learn another tool's scrīpting language. Testers need to remember that automation is software development, and it is important to have experience in one or more programming or scrīpting languages.
文章来源于http://www.whatistesting.com/interviews/edustin.htm
TAG: 混沌初期
