This document discusses agile testing and introduces Fit, a business-value centric testing tool. It summarizes Fit's key features like the column, row, and action fixtures used to arrange, assert, and sequence tests. The document advocates using Fit for acceptance test-driven development and outlines how a team can collaborate using Fit to write tests, develop code to pass tests, and ensure all tests remain passing.
Roots of Agility - Better Software Agile Dev Practices East 2014 KeynoteRob Myers
Rob provides a lightweight model for assessing past, present, and future processes, methodologies, management frameworks, practices, and values; and whether they can be considered to grow and nourish organizational agility. In a phrase: "Long-view, human-centric systems thinking."
The Business Value of Agile Engineering PracticesRob Myers
A brief overview of the Agile Engineering Practices, their costs and benefits, and using Lean's Value Stream Mapping and the Five Focusing Steps from the Theory of Constraints in order to evaluate the value of a practice. Also, what is expected from leadership while the practice is first being introduced.
The Business Value of Test-Driven DevelopmentRob Myers
High-level description of Test-Driven Development describing the costs and benefits of TDD. Value including reduction of defects, maintenance with confidence, and the ability to rapidly add innovative market-winning features.
The technical debt metaphor is useful in capturing the long-term impacts of
tradeoffs taken during software maintenance between productivity (getting
something done sooner) and maintainability (degradation of the code's
quality over time). This webinar on Technical Debt will present
techniques and insights that help software engineers to identify and track
technical debt in their projects. We will outline how business and product
quality goals should affect the choice of approaches (and combinations of
approaches) for managing technical debt. More specifically, we will discuss
a set of automated approaches based on static code analysis that are likely
to spot problems in source code that have real impact on productivity and
defect proneness. Based on previous empirical studies, we will give further
advice on which types of debt can be found by these tools, and which types
are not yet detectable.
Technical debt can crush a project, whether or not it's Agile. Rob describes technical debt and shows powerful practices that alleviate this "Agilist's Dilemma"
Roots of Agility - Better Software Agile Dev Practices East 2014 KeynoteRob Myers
Rob provides a lightweight model for assessing past, present, and future processes, methodologies, management frameworks, practices, and values; and whether they can be considered to grow and nourish organizational agility. In a phrase: "Long-view, human-centric systems thinking."
The Business Value of Agile Engineering PracticesRob Myers
A brief overview of the Agile Engineering Practices, their costs and benefits, and using Lean's Value Stream Mapping and the Five Focusing Steps from the Theory of Constraints in order to evaluate the value of a practice. Also, what is expected from leadership while the practice is first being introduced.
The Business Value of Test-Driven DevelopmentRob Myers
High-level description of Test-Driven Development describing the costs and benefits of TDD. Value including reduction of defects, maintenance with confidence, and the ability to rapidly add innovative market-winning features.
The technical debt metaphor is useful in capturing the long-term impacts of
tradeoffs taken during software maintenance between productivity (getting
something done sooner) and maintainability (degradation of the code's
quality over time). This webinar on Technical Debt will present
techniques and insights that help software engineers to identify and track
technical debt in their projects. We will outline how business and product
quality goals should affect the choice of approaches (and combinations of
approaches) for managing technical debt. More specifically, we will discuss
a set of automated approaches based on static code analysis that are likely
to spot problems in source code that have real impact on productivity and
defect proneness. Based on previous empirical studies, we will give further
advice on which types of debt can be found by these tools, and which types
are not yet detectable.
Technical debt can crush a project, whether or not it's Agile. Rob describes technical debt and shows powerful practices that alleviate this "Agilist's Dilemma"
Discusses using the Groovy dynamic language for primarily functional and acceptance testing with a forward looking perspective. Also considers polyglot options. The techniques and lessons learned can be applied to other kinds of testing and are also applicable to similar languages. Drivers and Runners discussed include: Native Groovy, HttpBuilder, HtmlUnitWebTest, Watij, Selenium, WebDriverTellurium, JWebUnit, JUnit, TestNG, Spock, EasyB, JBehave, Cucumber, Robot Framework and Slim
Fabio Sergio, creative director at frog design’s Milan studio, discusses the power of “design thinking for the future.” He uses a case study of Project M (a large-scale initiative that leverages mobile technologies to combat HIV/AIDS in South Africa) to illustrate a model of design that “is not about creating compelling visions of perfect futures but rather shaping betas of presents of a future we want to live in.”
Swiss Testing Day 2013 - How to avoid the testing swiss cheese syndromemarc.rambert
As a lot of teams suffer all over the world from the “Testing Swiss Cheese Syndrome” so I believe it is time to share the information that we have collected. By the end of this presentation, you should be able to make a first diagnostic on your testing activities and reflect on adapted medication.
To introduce you to this syndrome, let’s think about all the testing activities going on during an application development. It is usually a subset of unit testing, integration testing, functional testing, automated testing, manual testing, exploratory testing, etc.
It is very unlikely that a single testing activity covers the whole application. That’s where the similarity with a slide of Swiss cheese: you can imagine holes in your test coverage, areas that haven’t been covered by one testing activity.
The Swiss Cheese Syndrome appends when you don’t have an aggregated view of all these testing activities. In such a case, testing holes join their force to create tunnels where bugs and regressions can stay hidden until production.
The Business Value of Agile Engineering PracticesRob Myers
The AgileCamp Silicon Valley 2013 presentation: How do Agile Engineering Practices (aka Scrum Developer Practices) improve the throughput of real value? Rob starts off describing Lean value-stream mapping and the Theory of Constraints Five Focusing Steps in order to help organizations perform future evaluations. He then describes three of the most (in)famous of these practices: Test-Driven Development or TDD, Pair Programming, and Continuous Integration or CI.
Some categories of tech debt, their causes, potential metrics (and how to avoid their misuse), and ways to pay down the debt, and avoid the accrual of technical debt.
Talk first given at Agile Development Practices East 2011.
The Value of Refactoring on an Agile TeamRob Myers
Refactoring is often viewed as a technique to clean up existing messy code. If that were always true, then Agile projects would require up-front design, because teams rarely get around to those "big refactorings," and rarely will a Scrum PO or XP Customer buy (prioritize) a "refactoring story." In truth, Agile processes require design to emerge. Rob describes what it means to refactor clean, well-tested code. He demonstrates the actual business value of refactoring, and suggests ways to make sure refactoring and Emergent Design are given the necessary time to flourish.
More Related Content
Similar to Agile Testing: Solving the Agilist\'s Dilemma
Discusses using the Groovy dynamic language for primarily functional and acceptance testing with a forward looking perspective. Also considers polyglot options. The techniques and lessons learned can be applied to other kinds of testing and are also applicable to similar languages. Drivers and Runners discussed include: Native Groovy, HttpBuilder, HtmlUnitWebTest, Watij, Selenium, WebDriverTellurium, JWebUnit, JUnit, TestNG, Spock, EasyB, JBehave, Cucumber, Robot Framework and Slim
Fabio Sergio, creative director at frog design’s Milan studio, discusses the power of “design thinking for the future.” He uses a case study of Project M (a large-scale initiative that leverages mobile technologies to combat HIV/AIDS in South Africa) to illustrate a model of design that “is not about creating compelling visions of perfect futures but rather shaping betas of presents of a future we want to live in.”
Swiss Testing Day 2013 - How to avoid the testing swiss cheese syndromemarc.rambert
As a lot of teams suffer all over the world from the “Testing Swiss Cheese Syndrome” so I believe it is time to share the information that we have collected. By the end of this presentation, you should be able to make a first diagnostic on your testing activities and reflect on adapted medication.
To introduce you to this syndrome, let’s think about all the testing activities going on during an application development. It is usually a subset of unit testing, integration testing, functional testing, automated testing, manual testing, exploratory testing, etc.
It is very unlikely that a single testing activity covers the whole application. That’s where the similarity with a slide of Swiss cheese: you can imagine holes in your test coverage, areas that haven’t been covered by one testing activity.
The Swiss Cheese Syndrome appends when you don’t have an aggregated view of all these testing activities. In such a case, testing holes join their force to create tunnels where bugs and regressions can stay hidden until production.
The Business Value of Agile Engineering PracticesRob Myers
The AgileCamp Silicon Valley 2013 presentation: How do Agile Engineering Practices (aka Scrum Developer Practices) improve the throughput of real value? Rob starts off describing Lean value-stream mapping and the Theory of Constraints Five Focusing Steps in order to help organizations perform future evaluations. He then describes three of the most (in)famous of these practices: Test-Driven Development or TDD, Pair Programming, and Continuous Integration or CI.
Some categories of tech debt, their causes, potential metrics (and how to avoid their misuse), and ways to pay down the debt, and avoid the accrual of technical debt.
Talk first given at Agile Development Practices East 2011.
The Value of Refactoring on an Agile TeamRob Myers
Refactoring is often viewed as a technique to clean up existing messy code. If that were always true, then Agile projects would require up-front design, because teams rarely get around to those "big refactorings," and rarely will a Scrum PO or XP Customer buy (prioritize) a "refactoring story." In truth, Agile processes require design to emerge. Rob describes what it means to refactor clean, well-tested code. He demonstrates the actual business value of refactoring, and suggests ways to make sure refactoring and Emergent Design are given the necessary time to flourish.