作者:
Lisa Crispin
/
Janet Gregory 出版社: Addison-Wesley Professional 副标题: A Practical Guide for Testers and Agile Teams 出版年: 2009-1-9 页数: 576 定价: USD 57.99 装帧: Paperback ISBN: 9780321534460
Testing is a key component of agile development. The widespread adoption of agile methods has brought the need for effective testing into the limelight, and agile projects have transformed the role of testers. Much of a tester's function, however, remains largely misunderstood. What is the true role of a tester? Do agile teams actually need members with QA backgrounds? What doe...
Testing is a key component of agile development. The widespread adoption of agile methods has brought the need for effective testing into the limelight, and agile projects have transformed the role of testers. Much of a tester's function, however, remains largely misunderstood. What is the true role of a tester? Do agile teams actually need members with QA backgrounds? What does it really mean to be an "agile tester?" Two of the industry's most experienced agile testing practitioners and consultants, Lisa Crispin and Janet Gregory, have teamed up to bring you the definitive answers to these questions and many others. In Agile Testing, Crispin and Gregory define agile testing and illustrate the tester's role with examples from real agile teams. They teach you how to use the agile testing quadrants to identify what testing is needed, who should do it, and what tools might help. The book chronicles an agile software development iteration from the viewpoint of a tester and explains the seven key success factors of agile testing. Readers will come away from this book understanding * How to get testers engaged in agile development * Where testers and QA managers fit on an agile team * What to look for when hiring an agile tester * How to transition from a traditional cycle to agile development * How to complete testing activities in short iterations * How to use tests to successfully guide development * How to overcome barriers to test automationThis book is a must for agile testers, agile teams, their managers, and their customers.
Performance Testing from the Start
Ken De Souza, a software developer/tester at NCR [2008], responded to a question on the agile-testing mailing list about when to do stress and perfor- mance testing in an agile project with an explanation of how he approaches performance testing.
I'd suggest designing your performance tests from the start. We build data from the first iteration, and we run a simple performance test to make sure it all holds together. This is more to see that the functionality of the performance scripts holds together.
I used JMeter because I can hook FTP, SOAP, HTTP, RegEx, and so on, all from a few threads, with just one instance running. I can test out my calls right from the start (or at least have the infrastructure in place to do it).
My eventual goal is that when th... (查看原文)
 Agile Is All about Feedback Bret Pettichord, CTO of WatirCraft and co-author of Lessons Learned in Soft- ware Testing, shared these thoughts on the importance of feedback to agile development. Agile methods allow your team to get feedback regarding the software you are building. That’s the point. The feedback works on several levels. Pair programming gives developers instant feedback on t...
2012-04-01 15:54:03

Agile Is All about Feedback引自第485页
Bret Pettichord, CTO of WatirCraft and co-author of Lessons Learned in Soft- ware Testing, shared these thoughts on the importance of feedback to agile development.
Agile methods allow your team to get feedback regarding the software you are building. That’s the point. The feedback works on several levels. Pair programming gives developers instant feedback on their code. Sto- ries represent units of work where testers and analysts can give feed- back to developers. Iteration releases facilitate feedback from outside the team. Most agile practices are valuable because they create feed- back loops that allow teams to adapt.
A lot of teams adopt Agile with a grab-bag approach without quite real- izing the point of the practices. They pair-program without discussion or changing drivers. They send code to QA that the testers can’t test be- cause the story boundaries are arbitrary; they can’t tell whether they found a bug or just the end of the story. Iterations become schedule milestones rather than real opportunities to improve alignment and ad- just objectives.
The reason Agile teams can do with less planning is because feedback al- lows you to make sure that you are on course. If you don’t have mean- ingful feedback, then you’re not agile. You’re just in a new form of chaos.
On my last project, we defined our stories so that they made sense to everyone on the team. Our analysts, testers, and developers could all understand and review individual stories. But we found that we had to create a larger grouping, which we called features, to facilitate meaning- ful review from outside our team. We made sure all the stories in a fea- ture were complete before soliciting feedback from outside the team.
Being able to give and receive meaningful feedback is often a challenge for people. Yet it is crucial to success with Agile.
Agile teams get into terrible binds when executives or clients hand them a list of requirements at the start, tell them to use Agile (because it’s faster), and then don’t want to participate in the feedback process.
Agile isn’t faster all by itself. Agile is only a benefit in a world that ac- knowledges the value of adapting. And that adaptability needs to go all the way to whoever is funding the project. It is not enough for the team to be agile. The sponsors need to be agile too. Are all of the require- ments really required? Do we know exactly what the software needs to look like from the start?
Agile is faster because feedback allows you to find and focus on the most valuable features. If you are certain you know what needs to be built, don’t use Agile. If you don’t have time to gather and act on feed- back from customers, then don’t use Agile. If you are sure that everyone understands exactly what needs to be done from the start, then don’t use Agile.
Agile practices build a technical and organizational infrastructure to facil- itate getting and acting on feedback. If you aren’t going to adapt to feedback, then this infrastructure is waste that will only slow you down.
To us, the value of agile development isn’t that it’s faster but that it delivers enough value quickly enough to help the business grow and succeed. Testers play a key role in providing the feedback that allows that to happen.
SUCCESS FACTOR 1: USE THE WHOLE-TEAM APPROACH When the whole development team takes responsibility for testing and qual- ity, you have a large variety of skill sets and experience levels taking on what- ever testing issues might arrive. Test automation isn’t a big problem to a group of skilled programmers. When testing is a team priority, and anyone can sign up for testing tasks, the team desi...
2012-04-01 15:52:58
SUCCESS FACTOR 1: USE THE WHOLE-TEAM APPROACH
When the whole development team takes responsibility for testing and qual- ity, you have a large variety of skill sets and experience levels taking on what- ever testing issues might arrive. Test automation isn’t a big problem to a group of skilled programmers. When testing is a team priority, and anyone can sign up for testing tasks, the team designs testable code.引自第482页
Testers will conduct manual exploratory testing to find important bugs that defined test cases might miss. Testers might pair with other developers to automate and exe- cute test cases as coding on each story proceeds. Automated functional tests are added to the regression test suite. When tests demonstrating minimum functionality are complete, the team can consider the story finished.
2011-04-14 15:59:51
Testers will conduct manual exploratory testing to find important bugs that defined test cases might miss. Testers might pair with other developers to automate and exe- cute test cases as coding on each story proceeds. Automated functional tests are added to the regression test suite. When tests demonstrating minimum functionality are complete, the team can consider the story finished.引自第14页
Tester Bill of Rights. You have the right to bring up issues related to testing, quality, and process at any time. You have the right to ask questions of customers, programmers, and other team members and receive timely answers. You have the right to ask for and receive help from anyone on the project teams, including programmers, managers, and customers. You have the right to estimate testing ...
2011-05-16 20:49:20
Tester Bill of Rights.
You have the right to bring up issues related to testing, quality, and process at
any time.
You have the right to ask questions of customers, programmers, and other
team members and receive timely answers.
You have the right to ask for and receive help from anyone on the project
teams, including programmers, managers, and customers.
You have the right to estimate testing tasks and have these included in story
estimates.
You have the right to the tools you need to perform testing tasks in a timely
manner.
You have the right to expect your entire team, not just yourself, to be responsi-
ble for quality and testing.
—Lisa
 Agile Is All about Feedback Bret Pettichord, CTO of WatirCraft and co-author of Lessons Learned in Soft- ware Testing, shared these thoughts on the importance of feedback to agile development. Agile methods allow your team to get feedback regarding the software you are building. That’s the point. The feedback works on several levels. Pair programming gives developers instant feedback on t...
2012-04-01 15:54:03

Agile Is All about Feedback引自第485页
Bret Pettichord, CTO of WatirCraft and co-author of Lessons Learned in Soft- ware Testing, shared these thoughts on the importance of feedback to agile development.
Agile methods allow your team to get feedback regarding the software you are building. That’s the point. The feedback works on several levels. Pair programming gives developers instant feedback on their code. Sto- ries represent units of work where testers and analysts can give feed- back to developers. Iteration releases facilitate feedback from outside the team. Most agile practices are valuable because they create feed- back loops that allow teams to adapt.
A lot of teams adopt Agile with a grab-bag approach without quite real- izing the point of the practices. They pair-program without discussion or changing drivers. They send code to QA that the testers can’t test be- cause the story boundaries are arbitrary; they can’t tell whether they found a bug or just the end of the story. Iterations become schedule milestones rather than real opportunities to improve alignment and ad- just objectives.
The reason Agile teams can do with less planning is because feedback al- lows you to make sure that you are on course. If you don’t have mean- ingful feedback, then you’re not agile. You’re just in a new form of chaos.
On my last project, we defined our stories so that they made sense to everyone on the team. Our analysts, testers, and developers could all understand and review individual stories. But we found that we had to create a larger grouping, which we called features, to facilitate meaning- ful review from outside our team. We made sure all the stories in a fea- ture were complete before soliciting feedback from outside the team.
Being able to give and receive meaningful feedback is often a challenge for people. Yet it is crucial to success with Agile.
Agile teams get into terrible binds when executives or clients hand them a list of requirements at the start, tell them to use Agile (because it’s faster), and then don’t want to participate in the feedback process.
Agile isn’t faster all by itself. Agile is only a benefit in a world that ac- knowledges the value of adapting. And that adaptability needs to go all the way to whoever is funding the project. It is not enough for the team to be agile. The sponsors need to be agile too. Are all of the require- ments really required? Do we know exactly what the software needs to look like from the start?
Agile is faster because feedback allows you to find and focus on the most valuable features. If you are certain you know what needs to be built, don’t use Agile. If you don’t have time to gather and act on feed- back from customers, then don’t use Agile. If you are sure that everyone understands exactly what needs to be done from the start, then don’t use Agile.
Agile practices build a technical and organizational infrastructure to facil- itate getting and acting on feedback. If you aren’t going to adapt to feedback, then this infrastructure is waste that will only slow you down.
To us, the value of agile development isn’t that it’s faster but that it delivers enough value quickly enough to help the business grow and succeed. Testers play a key role in providing the feedback that allows that to happen.
SUCCESS FACTOR 1: USE THE WHOLE-TEAM APPROACH When the whole development team takes responsibility for testing and qual- ity, you have a large variety of skill sets and experience levels taking on what- ever testing issues might arrive. Test automation isn’t a big problem to a group of skilled programmers. When testing is a team priority, and anyone can sign up for testing tasks, the team desi...
2012-04-01 15:52:58
SUCCESS FACTOR 1: USE THE WHOLE-TEAM APPROACH
When the whole development team takes responsibility for testing and qual- ity, you have a large variety of skill sets and experience levels taking on what- ever testing issues might arrive. Test automation isn’t a big problem to a group of skilled programmers. When testing is a team priority, and anyone can sign up for testing tasks, the team designs testable code.引自第482页
software company during the time we wrote this book, gave us the following examples of metrics his team provides to their PMO. Testexecutionnumbersbystoryandfunctionalarea Testautomationstatus(numberoftestsautomatedvs.manual) Linegraphofthenumberoftestspassing/failingovertime Summaryandstatusofeachstory Defectmetrics SUMMARY At this point in our example iteration, our a...
2012-04-01 15:14:24
software company during the time we wrote this book, gave us the following examples of metrics his team provides to their PMO.
Testexecutionnumbersbystoryandfunctionalarea
Testautomationstatus(numberoftestsautomatedvs.manual) Linegraphofthenumberoftestspassing/failingovertime
Summaryandstatusofeachstory
Defectmetrics引自第440页
SUMMARY
At this point in our example iteration, our agile tester works closely with pro- grammers, customers, and other team members to produce stories in small testing-coding-reviewing-testing increments. Some points to keep in mind are:
Codingandtestingarepartofoneprocessduringtheiteration.
Writedetailedtestsforastoryassoonascodingbegins.
Drivedevelopmentbystartingwithasimpletest;whenthesimple
tests pass, write more complex test cases to further guide coding.
Usesimpleriskassessmenttechniquestohelpfocustestingefforts.
Usethe“PowerofThree”whenrequirementsaren’tclearoropinions
vary.
Focusoncompletingonestoryatatime.
Collaboratecloselywithprogrammerssothattestingandcodingare
integrated.
Teststhatcritiquetheproductarepartofdevelopment.
Keepcustomersintheloopthroughouttheiteration;letthemreview
early and often.
Everyoneontheteamcanworkontestingtasks.
 Testerscanfacilitatecommunicationbetweenthecustomerteamand development team.
Determinewhatthebest“bugfixing”choiceforyourteamis,buta good goal is to aim to have no bugs by release time.
Addnewautomatedteststotheregressionsuiteandscheduleittorun often enough to provide adequate feedback.
Manualexploratorytestinghelpsfindmissingrequirementsafterall the application has been coded.
Collaboratewithotherexpertstogettheresourcesandinfrastructure needed to complete testing.
Considerwhatmetricsyouneedduringtheiteration;progressand defect metrics are two examples.引自第440页
0 有用 白色的蓝 2012-04-01 16:04:30
看了很久! 可以称之为test 2.0(1.0个人认为是 Ron Patton这本 http://book.douban.com/subject/1761758/)
0 有用 透明 2010-11-23 23:47:00
每一章的脑图非常有爱
0 有用 BanditJohnson 2012-08-29 15:10:27
已经有了太多关于敏捷世界中Developer的书,而关于既有的Tester/QC/QA,他们如何在敏捷世界里傲游?这本书可以给你一些解读,至少。
0 有用 init.d 2010-11-10 13:11:32
跳着读完的,基本上并不是告诉你怎么进行敏捷测试,而是教你注重在向敏捷转变的过程中,QA的位置在哪里,怎么和团队沟通。QA在敏捷里要成功需要比原来更强势的地位,初级员工是做不了QA的,因为他没有办法挑战senior member,master和leader需要给予QA更大的支持才行,没有尚方宝剑的话,QA在敏捷里的位置会变得十分尴尬。
0 有用 eminemheaton 2015-05-08 12:51:51
转行了,没时间读完了~~比直接看中文版效果好。 15.2
0 有用 eminemheaton 2015-05-08 12:51:51
转行了,没时间读完了~~比直接看中文版效果好。 15.2
0 有用 Joe 2014-09-22 16:17:34
可以了解一些概念性的内容,对实际工作没什么指导作用
0 有用 BanditJohnson 2012-08-29 15:10:27
已经有了太多关于敏捷世界中Developer的书,而关于既有的Tester/QC/QA,他们如何在敏捷世界里傲游?这本书可以给你一些解读,至少。
0 有用 白色的蓝 2012-04-01 16:04:30
看了很久! 可以称之为test 2.0(1.0个人认为是 Ron Patton这本 http://book.douban.com/subject/1761758/)
0 有用 透明 2010-11-23 23:47:00
每一章的脑图非常有爱