I have been thinking, how to dig out the essence, why do we need Test Automation and Continuous Integration. Also how to help people to understand why these things are really important, when we are doing more fast paced software development.
I came up with two Workshops which are related to one another. In this blog post, I'll explain the concept of Feedback Loops and there will be two more posts, which are describing those Workshops more carefully.
So what do I mean with Feedback Loops? Feedback Loops are the things, when people who are developing the product starts to get feedback. Did he/she provide right kind of behavior to the product? In the end, customer is the one who gives the final verdict, does it do what they want.
These Feedback Loops can be something like this:
IDE
Unit Tests
Gollegue
Acceptance Tests
System Tests
Load Tests
...
Customer
And why are these so important? I have used this wine metaphor before. Abnormal behaviour is not like a wine, it does not get better with age. The sooner you catch and fix the abnormality, the better. What do you think, which one of these scenarios is cheaper? Customer finds a performance problem, which is caused by an architectural flaw vs. create small functionality based to the architecture and test it as soon as possible.
These thing are not directly tied to the Test Automation and Continuous Integration, but with the knowledge what I have, those things are mandatory to create as fast feedback as it can be.
Like I promised, following two posts will be about those workshops, so stay tuned.
I came up with two Workshops which are related to one another. In this blog post, I'll explain the concept of Feedback Loops and there will be two more posts, which are describing those Workshops more carefully.
 |
| Copyright Robin Stott and licensed for reuse under this Creative Commons Licence. |
These Feedback Loops can be something like this:
IDE
Unit Tests
Gollegue
Acceptance Tests
System Tests
Load Tests
...
Customer
And why are these so important? I have used this wine metaphor before. Abnormal behaviour is not like a wine, it does not get better with age. The sooner you catch and fix the abnormality, the better. What do you think, which one of these scenarios is cheaper? Customer finds a performance problem, which is caused by an architectural flaw vs. create small functionality based to the architecture and test it as soon as possible.
These thing are not directly tied to the Test Automation and Continuous Integration, but with the knowledge what I have, those things are mandatory to create as fast feedback as it can be.
Like I promised, following two posts will be about those workshops, so stay tuned.
