狠狠撸shows by User: ehendrickson
/
http://www.slideshare.net/images/logo.gif狠狠撸shows by User: ehendrickson
/
Fri, 26 Jul 2019 00:54:43 GMT狠狠撸Share feed for 狠狠撸shows by User: ehendricksonInfluence > Authority
/slideshow/influence-authority/157961690
testbashsf2018-hendrickson-influence-190726005443 Presented at TestBash 2018 San Francisco
You're a leader even if you don't think you are. Everyone is. But not everyone realizes it. Like Dorothy stuck in Oz, you have had your red shoes with you all along.
In this talk, we'll look at what leadership is and isn't, why influence is much more important than authority, and how to wield and grow your influence to have a positive impact on your organization.
Along the way, you'll learn how to leverage a set of underlying core principles such as:
- Don't Be Nice, Be Kind;
- Shave the Right Yak;
- To Fix a Problem, First Make it Visible;
- Fear is a Lousy Compass;
- To Increase the Intelligence of an Organization, Increase the Connections Within It;
- Positive Feedback Is More Powerful Than Criticism;
- and Shifting a Boundary a Few Inches Can Drastically Change an Outcome.
Oh, yes, and of course there will be stories. So. Many. Stories.]]>
Presented at TestBash 2018 San Francisco
You're a leader even if you don't think you are. Everyone is. But not everyone realizes it. Like Dorothy stuck in Oz, you have had your red shoes with you all along.
In this talk, we'll look at what leadership is and isn't, why influence is much more important than authority, and how to wield and grow your influence to have a positive impact on your organization.
Along the way, you'll learn how to leverage a set of underlying core principles such as:
- Don't Be Nice, Be Kind;
- Shave the Right Yak;
- To Fix a Problem, First Make it Visible;
- Fear is a Lousy Compass;
- To Increase the Intelligence of an Organization, Increase the Connections Within It;
- Positive Feedback Is More Powerful Than Criticism;
- and Shifting a Boundary a Few Inches Can Drastically Change an Outcome.
Oh, yes, and of course there will be stories. So. Many. Stories.]]>
Fri, 26 Jul 2019 00:54:43 GMT/slideshow/influence-authority/157961690ehendrickson@slideshare.net(ehendrickson)Influence > AuthorityehendricksonPresented at TestBash 2018 San Francisco
You're a leader even if you don't think you are. Everyone is. But not everyone realizes it. Like Dorothy stuck in Oz, you have had your red shoes with you all along.
In this talk, we'll look at what leadership is and isn't, why influence is much more important than authority, and how to wield and grow your influence to have a positive impact on your organization.
Along the way, you'll learn how to leverage a set of underlying core principles such as:
- Don't Be Nice, Be Kind;
- Shave the Right Yak;
- To Fix a Problem, First Make it Visible;
- Fear is a Lousy Compass;
- To Increase the Intelligence of an Organization, Increase the Connections Within It;
- Positive Feedback Is More Powerful Than Criticism;
- and Shifting a Boundary a Few Inches Can Drastically Change an Outcome.
Oh, yes, and of course there will be stories. So. Many. Stories.<img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/testbashsf2018-hendrickson-influence-190726005443-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> Presented at TestBash 2018 San Francisco
You're a leader even if you don't think you are. Everyone is. But not everyone realizes it. Like Dorothy stuck in Oz, you have had your red shoes with you all along.
In this talk, we'll look at what leadership is and isn't, why influence is much more important than authority, and how to wield and grow your influence to have a positive impact on your organization.
Along the way, you'll learn how to leverage a set of underlying core principles such as:
- Don't Be Nice, Be Kind;
- Shave the Right Yak;
- To Fix a Problem, First Make it Visible;
- Fear is a Lousy Compass;
- To Increase the Intelligence of an Organization, Increase the Connections Within It;
- Positive Feedback Is More Powerful Than Criticism;
- and Shifting a Boundary a Few Inches Can Drastically Change an Outcome.
Oh, yes, and of course there will be stories. So. Many. Stories.
]]>
3023https://cdn.slidesharecdn.com/ss_thumbnails/testbashsf2018-hendrickson-influence-190726005443-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0Agility for Data
/slideshow/agility-for-data/95877868
agiledeliver2018-hendrickson-agility4data-180503212505 Here鈥檚 the thing about data: it鈥檚 sticky, often rigid, and rarely feels agile. Yes, there are patterns that help increase the agility of data. Ruby on Rails, for example, has data migrations that not just allow but actively encourage incremental schema design. However all too often we hear about relational databases becoming a defacto API between subsystems, and thus resistant to change. It鈥檚 not just relational databases. Even supposedly unstructured data stored as key value pairs can be difficult to change if every piece of code that uses the data has duplicated logic to manage the semantic meaning of the data. Further, in-database logic such as rules, stored procedures, or user defined functions can be remarkably difficult to unit test. Finally, there are the often strict data governance requirements that necessitate keeping tight authorization control. Application developers have a wealth of tools and practices available to support incremental delivery. System administrators have DevOps tools and practices to support repeatable, automated operations. Where are the equivalents for data-centric work? Bringing agility to your data strategy may feel like an impossible goal, but it is possible. In this talk we consider the various ways in which data can impede agility, and how to make data strategies more agile-friendly.]]>
Here鈥檚 the thing about data: it鈥檚 sticky, often rigid, and rarely feels agile. Yes, there are patterns that help increase the agility of data. Ruby on Rails, for example, has data migrations that not just allow but actively encourage incremental schema design. However all too often we hear about relational databases becoming a defacto API between subsystems, and thus resistant to change. It鈥檚 not just relational databases. Even supposedly unstructured data stored as key value pairs can be difficult to change if every piece of code that uses the data has duplicated logic to manage the semantic meaning of the data. Further, in-database logic such as rules, stored procedures, or user defined functions can be remarkably difficult to unit test. Finally, there are the often strict data governance requirements that necessitate keeping tight authorization control. Application developers have a wealth of tools and practices available to support incremental delivery. System administrators have DevOps tools and practices to support repeatable, automated operations. Where are the equivalents for data-centric work? Bringing agility to your data strategy may feel like an impossible goal, but it is possible. In this talk we consider the various ways in which data can impede agility, and how to make data strategies more agile-friendly.]]>
Thu, 03 May 2018 21:25:05 GMT/slideshow/agility-for-data/95877868ehendrickson@slideshare.net(ehendrickson)Agility for DataehendricksonHere鈥檚 the thing about data: it鈥檚 sticky, often rigid, and rarely feels agile. Yes, there are patterns that help increase the agility of data. Ruby on Rails, for example, has data migrations that not just allow but actively encourage incremental schema design. However all too often we hear about relational databases becoming a defacto API between subsystems, and thus resistant to change. It鈥檚 not just relational databases. Even supposedly unstructured data stored as key value pairs can be difficult to change if every piece of code that uses the data has duplicated logic to manage the semantic meaning of the data. Further, in-database logic such as rules, stored procedures, or user defined functions can be remarkably difficult to unit test. Finally, there are the often strict data governance requirements that necessitate keeping tight authorization control. Application developers have a wealth of tools and practices available to support incremental delivery. System administrators have DevOps tools and practices to support repeatable, automated operations. Where are the equivalents for data-centric work? Bringing agility to your data strategy may feel like an impossible goal, but it is possible. In this talk we consider the various ways in which data can impede agility, and how to make data strategies more agile-friendly.<img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/agiledeliver2018-hendrickson-agility4data-180503212505-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> Here鈥檚 the thing about data: it鈥檚 sticky, often rigid, and rarely feels agile. Yes, there are patterns that help increase the agility of data. Ruby on Rails, for example, has data migrations that not just allow but actively encourage incremental schema design. However all too often we hear about relational databases becoming a defacto API between subsystems, and thus resistant to change. It鈥檚 not just relational databases. Even supposedly unstructured data stored as key value pairs can be difficult to change if every piece of code that uses the data has duplicated logic to manage the semantic meaning of the data. Further, in-database logic such as rules, stored procedures, or user defined functions can be remarkably difficult to unit test. Finally, there are the often strict data governance requirements that necessitate keeping tight authorization control. Application developers have a wealth of tools and practices available to support incremental delivery. System administrators have DevOps tools and practices to support repeatable, automated operations. Where are the equivalents for data-centric work? Bringing agility to your data strategy may feel like an impossible goal, but it is possible. In this talk we consider the various ways in which data can impede agility, and how to make data strategies more agile-friendly.
]]>
6132https://cdn.slidesharecdn.com/ss_thumbnails/agiledeliver2018-hendrickson-agility4data-180503212505-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0On the Care and Feeding of Feedback Cycles
/slideshow/care-and-feeding-of-feedback-cycles/27823505
hendrickson-feedback-cycles-131101173606-phpapp01 Presented at Flowcon SF on Nov 1, 2013
Nothing interrupts the continuous flow of value like bad surprises that require immediate attention: major defects; service outages; support escalations; or even scrapping just-completed capabilities that don't actually meet business needs.
You already know that the sooner you can discover a problem, the sooner and more smoothly you can remedy it. Agile practices involve testing early and often. However feedback comes in many forms, only some of which are traditionally considered testing. Continuous integration, acceptance testing with users, even cohort analysis to validate business hypotheses are all examples of feedback cycles.
This talk examines the many forms of feedback, the questions each can answer, and the risks each can mitigate. We'll take a fresh look at the churn and disruption created by having high feedback latency, when the time between taking an action and discovering its effect is too long. We'll also consider how addressing "bugs" that may not be detracting from the actual business value can distract us from addressing real risks. Along the way we'll consider fundamental principles that you can apply immediately to keep your feedback cycles healthy and happy. ]]>
Presented at Flowcon SF on Nov 1, 2013
Nothing interrupts the continuous flow of value like bad surprises that require immediate attention: major defects; service outages; support escalations; or even scrapping just-completed capabilities that don't actually meet business needs.
You already know that the sooner you can discover a problem, the sooner and more smoothly you can remedy it. Agile practices involve testing early and often. However feedback comes in many forms, only some of which are traditionally considered testing. Continuous integration, acceptance testing with users, even cohort analysis to validate business hypotheses are all examples of feedback cycles.
This talk examines the many forms of feedback, the questions each can answer, and the risks each can mitigate. We'll take a fresh look at the churn and disruption created by having high feedback latency, when the time between taking an action and discovering its effect is too long. We'll also consider how addressing "bugs" that may not be detracting from the actual business value can distract us from addressing real risks. Along the way we'll consider fundamental principles that you can apply immediately to keep your feedback cycles healthy and happy. ]]>
Fri, 01 Nov 2013 17:36:06 GMT/slideshow/care-and-feeding-of-feedback-cycles/27823505ehendrickson@slideshare.net(ehendrickson)On the Care and Feeding of Feedback CyclesehendricksonPresented at Flowcon SF on Nov 1, 2013
Nothing interrupts the continuous flow of value like bad surprises that require immediate attention: major defects; service outages; support escalations; or even scrapping just-completed capabilities that don't actually meet business needs.
You already know that the sooner you can discover a problem, the sooner and more smoothly you can remedy it. Agile practices involve testing early and often. However feedback comes in many forms, only some of which are traditionally considered testing. Continuous integration, acceptance testing with users, even cohort analysis to validate business hypotheses are all examples of feedback cycles.
This talk examines the many forms of feedback, the questions each can answer, and the risks each can mitigate. We'll take a fresh look at the churn and disruption created by having high feedback latency, when the time between taking an action and discovering its effect is too long. We'll also consider how addressing "bugs" that may not be detracting from the actual business value can distract us from addressing real risks. Along the way we'll consider fundamental principles that you can apply immediately to keep your feedback cycles healthy and happy. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/hendrickson-feedback-cycles-131101173606-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> Presented at Flowcon SF on Nov 1, 2013
Nothing interrupts the continuous flow of value like bad surprises that require immediate attention: major defects; service outages; support escalations; or even scrapping just-completed capabilities that don't actually meet business needs.
You already know that the sooner you can discover a problem, the sooner and more smoothly you can remedy it. Agile practices involve testing early and often. However feedback comes in many forms, only some of which are traditionally considered testing. Continuous integration, acceptance testing with users, even cohort analysis to validate business hypotheses are all examples of feedback cycles.
This talk examines the many forms of feedback, the questions each can answer, and the risks each can mitigate. We'll take a fresh look at the churn and disruption created by having high feedback latency, when the time between taking an action and discovering its effect is too long. We'll also consider how addressing "bugs" that may not be detracting from the actual business value can distract us from addressing real risks. Along the way we'll consider fundamental principles that you can apply immediately to keep your feedback cycles healthy and happy.
]]>
44345https://cdn.slidesharecdn.com/ss_thumbnails/hendrickson-feedback-cycles-131101173606-phpapp01-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0Agile Quality and Risk Management
/slideshow/to-aqarm-sm/24999604
toaqarmsm-130806150607-phpapp02 Traditional approaches to quality and risk management involve quality gates, change control boards, feature freeze and code freeze milestones, and independent QA or Test groups. These approaches stabilize quality at by sacrificing agility.
Yet buggy fragile code is even more dangerous for Agile teams where so much is changing so often. Quality and risk management are critically important for agility.
This leads to the inevitable question: if the traditional approaches to quality and risk management don't work in an Agile context, what does?
Practices vary across organizations, but all successful teams emphasize the same underlying principles of fast feedback, high visibility, collaboration, and alignment. This talk examines various approaches Agile teams have taken to increase quality, mitigate risk, and ultimately ensure they are delivering the highest possible value for their stakeholders.]]>
Traditional approaches to quality and risk management involve quality gates, change control boards, feature freeze and code freeze milestones, and independent QA or Test groups. These approaches stabilize quality at by sacrificing agility.
Yet buggy fragile code is even more dangerous for Agile teams where so much is changing so often. Quality and risk management are critically important for agility.
This leads to the inevitable question: if the traditional approaches to quality and risk management don't work in an Agile context, what does?
Practices vary across organizations, but all successful teams emphasize the same underlying principles of fast feedback, high visibility, collaboration, and alignment. This talk examines various approaches Agile teams have taken to increase quality, mitigate risk, and ultimately ensure they are delivering the highest possible value for their stakeholders.]]>
Tue, 06 Aug 2013 15:06:07 GMT/slideshow/to-aqarm-sm/24999604ehendrickson@slideshare.net(ehendrickson)Agile Quality and Risk ManagementehendricksonTraditional approaches to quality and risk management involve quality gates, change control boards, feature freeze and code freeze milestones, and independent QA or Test groups. These approaches stabilize quality at by sacrificing agility.
Yet buggy fragile code is even more dangerous for Agile teams where so much is changing so often. Quality and risk management are critically important for agility.
This leads to the inevitable question: if the traditional approaches to quality and risk management don't work in an Agile context, what does?
Practices vary across organizations, but all successful teams emphasize the same underlying principles of fast feedback, high visibility, collaboration, and alignment. This talk examines various approaches Agile teams have taken to increase quality, mitigate risk, and ultimately ensure they are delivering the highest possible value for their stakeholders.<img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/toaqarmsm-130806150607-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> Traditional approaches to quality and risk management involve quality gates, change control boards, feature freeze and code freeze milestones, and independent QA or Test groups. These approaches stabilize quality at by sacrificing agility.
Yet buggy fragile code is even more dangerous for Agile teams where so much is changing so often. Quality and risk management are critically important for agility.
This leads to the inevitable question: if the traditional approaches to quality and risk management don't work in an Agile context, what does?
Practices vary across organizations, but all successful teams emphasize the same underlying principles of fast feedback, high visibility, collaboration, and alignment. This talk examines various approaches Agile teams have taken to increase quality, mitigate risk, and ultimately ensure they are delivering the highest possible value for their stakeholders.
]]>
75518https://cdn.slidesharecdn.com/ss_thumbnails/thinkingtesterevolved-120717121646-phpapp02-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0Exploratory Testing in Practice
/slideshow/exploratory-testing-in-practice/13429615
ettalk-120623103819-phpapp01 What is this thing called "Exploratory Testing"? How do you do it? Why is it important?]]>
What is this thing called "Exploratory Testing"? How do you do it? Why is it important?]]>
Sat, 23 Jun 2012 10:38:18 GMT/slideshow/exploratory-testing-in-practice/13429615ehendrickson@slideshare.net(ehendrickson)Exploratory Testing in PracticeehendricksonWhat is this thing called "Exploratory Testing"? How do you do it? Why is it important?<img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/ettalk-120623103819-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> What is this thing called "Exploratory Testing"? How do you do it? Why is it important?
]]>
39727https://cdn.slidesharecdn.com/ss_thumbnails/ettalk-120623103819-phpapp01-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0#LFMF: Tales of Test Automation Gone Wrong
/slideshow/lfmf-tales-of-test-automation-fa/12954131
lfmf-120516054544-phpapp02 This is a "Best Of" list of my (and others) failures over the years in attempting to adopt test automation. In it, you'll find 13 categories of What Not to Do. Presented at Turku Agile Day 2012 (#tad012).]]>
This is a "Best Of" list of my (and others) failures over the years in attempting to adopt test automation. In it, you'll find 13 categories of What Not to Do. Presented at Turku Agile Day 2012 (#tad012).]]>
Wed, 16 May 2012 05:45:43 GMT/slideshow/lfmf-tales-of-test-automation-fa/12954131ehendrickson@slideshare.net(ehendrickson)#LFMF: Tales of Test Automation Gone Wrong ehendricksonThis is a "Best Of" list of my (and others) failures over the years in attempting to adopt test automation. In it, you'll find 13 categories of What Not to Do. Presented at Turku Agile Day 2012 (#tad012).<img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/lfmf-120516054544-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> This is a "Best Of" list of my (and others) failures over the years in attempting to adopt test automation. In it, you'll find 13 categories of What Not to Do. Presented at Turku Agile Day 2012 (#tad012).
]]>
232812https://cdn.slidesharecdn.com/ss_thumbnails/lfmf-120516054544-phpapp02-thumbnail.jpg?width=120&height=120&fit=boundspresentationWhitehttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0AGILEEE Friday 17:15 Talk
/slideshow/agileee-friday-1715-talk-9390480/9390480
agileriskagileeeprint-110923065510-phpapp02 The original title of this talk is "Agile Testing, Uncertainty, Risk, and Why It All Works." That's still the topic of this talk, however after hearing so many misconceptions about testing simply because the name "Test" carries so much baggage in our industry, I decided to reframe my talk so as to avoid using the word "Test" at all in the first half. Instead, we'll focus on how fast feedback supports learning and empirical evidence trumps speculation.]]>
The original title of this talk is "Agile Testing, Uncertainty, Risk, and Why It All Works." That's still the topic of this talk, however after hearing so many misconceptions about testing simply because the name "Test" carries so much baggage in our industry, I decided to reframe my talk so as to avoid using the word "Test" at all in the first half. Instead, we'll focus on how fast feedback supports learning and empirical evidence trumps speculation.]]>
Fri, 23 Sep 2011 06:55:06 GMT/slideshow/agileee-friday-1715-talk-9390480/9390480ehendrickson@slideshare.net(ehendrickson)AGILEEE Friday 17:15 TalkehendricksonThe original title of this talk is "Agile Testing, Uncertainty, Risk, and Why It All Works." That's still the topic of this talk, however after hearing so many misconceptions about testing simply because the name "Test" carries so much baggage in our industry, I decided to reframe my talk so as to avoid using the word "Test" at all in the first half. Instead, we'll focus on how fast feedback supports learning and empirical evidence trumps speculation.<img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/agileriskagileeeprint-110923065510-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> The original title of this talk is "Agile Testing, Uncertainty, Risk, and Why It All Works." That's still the topic of this talk, however after hearing so many misconceptions about testing simply because the name "Test" carries so much baggage in our industry, I decided to reframe my talk so as to avoid using the word "Test" at all in the first half. Instead, we'll focus on how fast feedback supports learning and empirical evidence trumps speculation.
]]>
44807https://cdn.slidesharecdn.com/ss_thumbnails/etinagile-agile2011-final-110822190158-phpapp02-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0Entaggle: an Agile Software Development Case Study
/slideshow/entaggle-an-agile-software-development-case-study/7606365
entaggleagility-110412165514-phpapp02 ]]>
]]>
Tue, 12 Apr 2011 16:55:11 GMT/slideshow/entaggle-an-agile-software-development-case-study/7606365ehendrickson@slideshare.net(ehendrickson)Entaggle: an Agile Software Development Case Studyehendrickson<img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/entaggleagility-110412165514-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds" /><br>
]]>
11744https://cdn.slidesharecdn.com/ss_thumbnails/wclessons-atd-sm-101007215742-phpapp01-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0Agile Testing, Uncertainty, Risk, and Why It All Works
/ehendrickson/agile-testing-uncertainty-risk-and-why-it-all-works
aturawiaw-100629121419-phpapp01 Testing is integral to any Agile development process. This slide deck offers an overview of Agile testing-related practices and explains how they work together to mitigate the most common sources of risk on any project.]]>
Testing is integral to any Agile development process. This slide deck offers an overview of Agile testing-related practices and explains how they work together to mitigate the most common sources of risk on any project.]]>
Tue, 29 Jun 2010 12:14:11 GMT/ehendrickson/agile-testing-uncertainty-risk-and-why-it-all-worksehendrickson@slideshare.net(ehendrickson)Agile Testing, Uncertainty, Risk, and Why It All WorksehendricksonTesting is integral to any Agile development process. This slide deck offers an overview of Agile testing-related practices and explains how they work together to mitigate the most common sources of risk on any project.<img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/aturawiaw-100629121419-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> Testing is integral to any Agile development process. This slide deck offers an overview of Agile testing-related practices and explains how they work together to mitigate the most common sources of risk on any project.
]]>
12124https://cdn.slidesharecdn.com/ss_thumbnails/aturawiaw-100629121419-phpapp01-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0Agile Testing Overview
/slideshow/agile-testing-u/4458320
aturawiaw-100609212643-phpapp02 An explanation of how Agile Testing practices work together to mitigate risk.]]>
An explanation of how Agile Testing practices work together to mitigate risk.]]>
Wed, 09 Jun 2010 21:20:48 GMT/slideshow/agile-testing-u/4458320ehendrickson@slideshare.net(ehendrickson)Agile Testing OverviewehendricksonAn explanation of how Agile Testing practices work together to mitigate risk.<img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/aturawiaw-100609212643-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> An explanation of how Agile Testing practices work together to mitigate risk.
]]>
23806https://cdn.slidesharecdn.com/ss_thumbnails/aturawiaw-100609212643-phpapp02-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0Introduction to Acceptance Test Driven Development
/slideshow/introduction-to-acceptance-test-driven-development-3491703/3491703
atddoverview-100321030156-phpapp02 In The Seven Habits of Highly Effective People, Stephen R. Covey names "Begin with the End in Mind" as the second of the seven habits. This habit applies not just to individuals, but to software development teams as well. In Acceptance Test Driven Development (ATDD), the Product Owner begins requirements discussions with expectations and examples, and the whole team collaborates to distill these into acceptance tests that define the essence of 鈥淒one." Modern testing frameworks enable the team to express the tests in natural language while connecting them to the software so that the tests are automated while the software is being developed. The end result is that the acceptance tests become executable requirements.
These slides explain the ATDD cycle and how it fits with other Agile development and testing practices including TDD, Continuous Integration, and Exploratory Testing.]]>
In The Seven Habits of Highly Effective People, Stephen R. Covey names "Begin with the End in Mind" as the second of the seven habits. This habit applies not just to individuals, but to software development teams as well. In Acceptance Test Driven Development (ATDD), the Product Owner begins requirements discussions with expectations and examples, and the whole team collaborates to distill these into acceptance tests that define the essence of 鈥淒one." Modern testing frameworks enable the team to express the tests in natural language while connecting them to the software so that the tests are automated while the software is being developed. The end result is that the acceptance tests become executable requirements.
These slides explain the ATDD cycle and how it fits with other Agile development and testing practices including TDD, Continuous Integration, and Exploratory Testing.]]>
Sun, 21 Mar 2010 03:01:48 GMT/slideshow/introduction-to-acceptance-test-driven-development-3491703/3491703ehendrickson@slideshare.net(ehendrickson)Introduction to Acceptance Test Driven DevelopmentehendricksonIn The Seven Habits of Highly Effective People, Stephen R. Covey names "Begin with the End in Mind" as the second of the seven habits. This habit applies not just to individuals, but to software development teams as well. In Acceptance Test Driven Development (ATDD), the Product Owner begins requirements discussions with expectations and examples, and the whole team collaborates to distill these into acceptance tests that define the essence of 鈥淒one." Modern testing frameworks enable the team to express the tests in natural language while connecting them to the software so that the tests are automated while the software is being developed. The end result is that the acceptance tests become executable requirements.
These slides explain the ATDD cycle and how it fits with other Agile development and testing practices including TDD, Continuous Integration, and Exploratory Testing.<img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/atddoverview-100321030156-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> In The Seven Habits of Highly Effective People, Stephen R. Covey names "Begin with the End in Mind" as the second of the seven habits. This habit applies not just to individuals, but to software development teams as well. In Acceptance Test Driven Development (ATDD), the Product Owner begins requirements discussions with expectations and examples, and the whole team collaborates to distill these into acceptance tests that define the essence of 鈥淒one." Modern testing frameworks enable the team to express the tests in natural language while connecting them to the software so that the tests are automated while the software is being developed. The end result is that the acceptance tests become executable requirements.
These slides explain the ATDD cycle and how it fits with other Agile development and testing practices including TDD, Continuous Integration, and Exploratory Testing.
]]>
998115https://cdn.slidesharecdn.com/ss_thumbnails/atddoverview-100321030156-phpapp02-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0Agile: Get Real
/slideshow/hendrickson-agile-get-real-turku-agile-day/3491678
hendricksonagilegetrealturkuagileday-100321024755-phpapp01 Agile practices work because they force us to leave the world of speculation and 'get real.' These are the slides that I presented at Turku Agile Day, March 18, 2010.]]>
Agile practices work because they force us to leave the world of speculation and 'get real.' These are the slides that I presented at Turku Agile Day, March 18, 2010.]]>
Sun, 21 Mar 2010 02:47:45 GMT/slideshow/hendrickson-agile-get-real-turku-agile-day/3491678ehendrickson@slideshare.net(ehendrickson)Agile: Get RealehendricksonAgile practices work because they force us to leave the world of speculation and 'get real.' These are the slides that I presented at Turku Agile Day, March 18, 2010.<img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/hendricksonagilegetrealturkuagileday-100321024755-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> Agile practices work because they force us to leave the world of speculation and 'get real.' These are the slides that I presented at Turku Agile Day, March 18, 2010.
]]>
9392https://cdn.slidesharecdn.com/ss_thumbnails/hendricksonagilegetrealturkuagileday-100321024755-phpapp01-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0https://public.slidesharecdn.com/v2/images/profile-picture.pngOver 20 years software industry experience. Working with Agile teams since 2004. Certified Scrum Master, former member of the board of the Agile Alliance, and co-organizer of the Agile Alliance Functional Testing Tools program. Frequently invited speaker to major conferences on software development & testing.www.qualitytree.comhttps://cdn.slidesharecdn.com/ss_thumbnails/testbashsf2018-hendrickson-influence-190726005443-thumbnail.jpg?width=320&height=320&fit=boundsslideshow/influence-authority/157961690Influence > Authorityhttps://cdn.slidesharecdn.com/ss_thumbnails/agiledeliver2018-hendrickson-agility4data-180503212505-thumbnail.jpg?width=320&height=320&fit=boundsslideshow/agility-for-data/95877868Agility for Datahttps://cdn.slidesharecdn.com/ss_thumbnails/hendrickson-feedback-cycles-131101173606-phpapp01-thumbnail.jpg?width=320&height=320&fit=boundsslideshow/care-and-feeding-of-feedback-cycles/27823505On the Care and Feedin...