Feedback Loops

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.

Copyright Robin Stott and licensed for reuse under this Creative Commons Licence.

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.

Where the heck are we?

Your nightly build is red. There are some test cases failing and you know that this should be the moment when you need to stop and investigate. Your Product Owner runs in the team room and start to rant about features which must be in before the release at the end of the week. He is questioning are those faults so bad that we really need to consume time to fix them, because we have promised some cool stuff to our customer.

Roadsign to Lost farm near Bellabeg. (Stanley Howe) / CC BY-SA 2.0

What to do? Every time we have failing test case(s) in our build(s) it means that our location is unknown, failing test case says that behavior of our product is not what we have expected it to be and before those case(s) are green again, everything what you create are just hypothesis.

Abnormal situation is work need to be done, and it's work that does not get any better with age, actually quite the opposite. It's work which generates more work. On the other hand, if we use stop the belt and fix the problem immediately it causes idling to the rest of system and the bigger the system is, the bigger the effect of idling is. So what do? I think that abnormality should always be removed as soon as it is noticed. We should always have the best understanding where we are and get back on the map quickly.

Why automate your test cases?

Where this, maybe even very basic question came from? I talked with my old schoolmate and he had had a hard time to prove to his boss why they should automate some of their test cases. They are doing regression tests that people are executing before every release. To me it seemed like a very simple case, to automate what they were doing.

So why should test cases be automated? Feedback time is the key. With testing you are trying to find (and also trying to avoid) defects as soon as it has been presented to the code. With manual regression testing, this feedback loop is long and regression testing itself is time consuming which causes a problem in test coverage. With automation, you can have bigger set of test executed with shorter time and after creating good Continuous Integration system, there is no need of human interaction for regression test execution.

You can sleep your nights better, with good test automation. Because with it, you know all the time where you are with your Software.

Ps. You can find some Automation testing tools here.

Automation frameworks: Robot framework, Cucumber and Fitnnesse.
Continuous Integration Servers: Hudson and BuildBot

Our show in XP2010 and more

We had quite a good warm up band. Mark Streibeck from Google introduced us their Continuous Integration system and it was amazing! Everybody always committing to same head and it must be green all the time. Pretty mind blowing if you think that they have 1500+ product, 10000 developers and 60M+ test cases.

Anyway. My feeling about our presentation was pretty good. If you were there, please give me feedback. It was first time for me and Ran to write something for conference and it was an extremely good experience. I must continue with this path little bit further, because my opinion is that companies should do more scientific research.

The conference was facilitated greatly, everything from preparation of the conference itself to evening programs, or what can you say that we had Jazz musicians improvising and telling the theory about that (which is very close to pair programing) and later on there was a gig by an extreme metal band called Keep of Kalessin (you should check out this).

So, thank you very much and see ya!