How deep are your tests? Agile Cymru 2016TSundberg
Manual testing is most often done end-to-end. Tests are performed through the user interface. When testing gets automated, this is where most organisations start. They start with automating the way they do things now. The new way is faster, but it isn’t fast enough. And not robust enough.
It is unnecessarily complicated to understand why an end-to-end test fails. There are usually many different possibilities when something doesn’t work.
The number of possible paths through a reasonably large application will very fast make it impossible to cover them all. Combinatorics is your enemy.
The solution is to minimise the tests that passes through many layers in your application. Minimising doesn’t mean removing the end-to-end tests. They are still needed. But much fewer than most organisations seem to think.
I will show you why the testing pyramid need to be very wide. You will understand why this is an absolute necessity if all possible paths through the application should be tested.
In other words, let me show you why your tests must be very shallow.
Definition of done: Working software in productionTSundberg
When you are done with the development, you need to deploy the result. This presentation describes some tooling we used at MTM to implement Continuous Deployment.
How deep are your tests? Agile Cymru 2016TSundberg
Manual testing is most often done end-to-end. Tests are performed through the user interface. When testing gets automated, this is where most organisations start. They start with automating the way they do things now. The new way is faster, but it isn’t fast enough. And not robust enough.
It is unnecessarily complicated to understand why an end-to-end test fails. There are usually many different possibilities when something doesn’t work.
The number of possible paths through a reasonably large application will very fast make it impossible to cover them all. Combinatorics is your enemy.
The solution is to minimise the tests that passes through many layers in your application. Minimising doesn’t mean removing the end-to-end tests. They are still needed. But much fewer than most organisations seem to think.
I will show you why the testing pyramid need to be very wide. You will understand why this is an absolute necessity if all possible paths through the application should be tested.
In other words, let me show you why your tests must be very shallow.
Definition of done: Working software in productionTSundberg
When you are done with the development, you need to deploy the result. This presentation describes some tooling we used at MTM to implement Continuous Deployment.
Walking Skeleton as presented at ACCU 2015 in Bristol, EnglandTSundberg
A Walking Skeleton has been described by Alistair Cockburn as 'a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.' It is also the theme of the popular book 'Growing Object Orientated Software Guided by Tests' by Steve Freeman and Nat Pryce.
In this session Thomas will start with a clean development environment and develop a walking skeleton for an application. The skeleton will evolve and parts will be added as we gather more and more knowledge about the system we are building.
This will demonstrate how Acceptance Test Driven Development (ATDD) and Test Driven Development (TDD) can be used to drive the development of a Walking Skeleton, keep it running, and grow it incrementally.
Selenium and the Four Rules of Simple DesignTSundberg
These are the slides from my presentation at Selenium Camp 2015 in Kiev, Ukraine.
The source code that I wrote during the presentation is available at GitHub, https://github.com/tsundberg/Selenium-and-the-Four-Rules-of-Simple-Design/commits/SeleniumCamp-2015
The Responsible Developer - XP days Ukraine 2014TSundberg
Developers are the translators between ideas and code. They translate ideas about functionality to code so the end users can benefit from a usable program. This translation has to be done in a careful and responsible way. It should be done by a responsible developer.
What is a responsible developer then?
It is a developer that writes clean, testable and maintainable code. A developer who can explain and describe his work. Someone that knows that he grows by helping his fellow developers and never settles for second best.
I will discuss the properties of a responsible developer and suggest ways you can improve to become a responsible developer.ccc
BDD with Cucumber-JVM as presented at I T.A.K.E. Unconference in Bucharest 2014TSundberg
Behaviour Driven Development, BDD, is a way to increase communication between stakeholders in a project and at the same time create executable examples.
(Remote) Pair Programming as it was presented at 33rd Degree 4 charity at 13 October 2013, Krakow, Poland
Programming is often something that is done in solitude. Problem solving is something that often is done in a group. Programming is always about problem solving. It is therefore natural to do programming in groups. The group must not be too large and there must be at least two persons to make up a reasonable group. A pair turns out as the natural choice.
Some of the benefits with pair programming are
- Problem solving
- Continuous reviews
- Quality
- Learning
- Lower project risks
- Satisfaction
Pair programming is most efficient when the pair sits next to each other. This is not always possible. I will therefore show how to setup a remote pair programming session and then do some programming with a remote partner.
There is a myth that pair programming is twice as expensive as having one person solve each problem. The actual direct cost has been shown to be only 15% higher.
Walking Skeleton as presented at ACCU 2015 in Bristol, EnglandTSundberg
A Walking Skeleton has been described by Alistair Cockburn as 'a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.' It is also the theme of the popular book 'Growing Object Orientated Software Guided by Tests' by Steve Freeman and Nat Pryce.
In this session Thomas will start with a clean development environment and develop a walking skeleton for an application. The skeleton will evolve and parts will be added as we gather more and more knowledge about the system we are building.
This will demonstrate how Acceptance Test Driven Development (ATDD) and Test Driven Development (TDD) can be used to drive the development of a Walking Skeleton, keep it running, and grow it incrementally.
Selenium and the Four Rules of Simple DesignTSundberg
These are the slides from my presentation at Selenium Camp 2015 in Kiev, Ukraine.
The source code that I wrote during the presentation is available at GitHub, https://github.com/tsundberg/Selenium-and-the-Four-Rules-of-Simple-Design/commits/SeleniumCamp-2015
The Responsible Developer - XP days Ukraine 2014TSundberg
Developers are the translators between ideas and code. They translate ideas about functionality to code so the end users can benefit from a usable program. This translation has to be done in a careful and responsible way. It should be done by a responsible developer.
What is a responsible developer then?
It is a developer that writes clean, testable and maintainable code. A developer who can explain and describe his work. Someone that knows that he grows by helping his fellow developers and never settles for second best.
I will discuss the properties of a responsible developer and suggest ways you can improve to become a responsible developer.ccc
BDD with Cucumber-JVM as presented at I T.A.K.E. Unconference in Bucharest 2014TSundberg
Behaviour Driven Development, BDD, is a way to increase communication between stakeholders in a project and at the same time create executable examples.
(Remote) Pair Programming as it was presented at 33rd Degree 4 charity at 13 October 2013, Krakow, Poland
Programming is often something that is done in solitude. Problem solving is something that often is done in a group. Programming is always about problem solving. It is therefore natural to do programming in groups. The group must not be too large and there must be at least two persons to make up a reasonable group. A pair turns out as the natural choice.
Some of the benefits with pair programming are
- Problem solving
- Continuous reviews
- Quality
- Learning
- Lower project risks
- Satisfaction
Pair programming is most efficient when the pair sits next to each other. This is not always possible. I will therefore show how to setup a remote pair programming session and then do some programming with a remote partner.
There is a myth that pair programming is twice as expensive as having one person solve each problem. The actual direct cost has been shown to be only 15% higher.