failing fast

Failing Fast

Reading Time 3 minutes

Failing fast leads to one thing, Success

It is important that your code base, continuous integration, tools and even your processes are able to fail fast. Human’s are a different consideration.

Why should a given process fail fast? What value is there in failing quickly?

Failing Fast

The greatest value in failing quickly is perhaps the ability to react to changes quickly.

Why fail fast? Failing quickly helps to resolve issues quicker since they are surfaced sooner. Let’s have a look at some of them:

Bug Cost

The earlier a bug is caught, the cheaper it is to fix

Wait, what does that mean? Cheaper in what sense, money, time, fingers?

Depending on the stage at which a bug is captured, the cheaper or quicker it may be to fix. It is therefore in your interest to fail quickly.

Let’s assume that a developer is working on a feature branch which is yet to be ‘merged’ into the master code base. Assume that a bug was found on the branch before the code was merged. Now let’s assume the same bug was found sometime after the code was merged.

In the above scenario, would the bug be easier and potentially quicker to fix before or after the merge? Does it even matter?

You can bet your bottom that it absolutely matters!

The sooner a bug is found between planning and deployment, the quicker it is to fix. Having to fix a bug with less code and less overhead makes it easier and quicker to fix.

Failing quickly directly impacts bug cost

Test Pyramid

What is the Test Pyramid?

The Test Pyramid is the principle of rationally dividing up the number of ‘types of tests’ one may write for an application. This is what the pyramid looks like:
testing pyramid

The length of each slice in the pyramid represents the number of tests you would write.

In short, the principle here is to write many unit tests, some integration and very few UI tests. Enough theory, how does this help to capture failures quickly?

The lower the test form, the quicker it runs!

Unit tests run faster than integration tests, integration tests are quicker than UI tests and UI tests are the slowest horse in the race. Let’s not get into the why or how, just take my word for it.

If we accept this concept, then this directly can help us to fail quickly. For instance, if we capture a bug on the unit test level, it would be quicker to fix since we found it quicker.

In conclusion, if a bug is not capture in a unit test and instead a UI test, it may be more expensive to fix.

Learn Quickly, Make New Mistakes

Failing quickly provides an opportunity to learn quickly

If you are able to fail quickly, this helps to promote learning.

As a result, the probability of repeating the same mistake should decrease. Consequently, this also means the probability of making new mistakes should increase.

In Agile, this is an important concept. This effectively means to quickly translate an issue into a learning outcome.

Failing Quickly, Any Real Benefits?

It should be clear that failing quickly does hold a lot of benefits, the biggest perhaps being able to adapt to changes.

We should absolutely leverage existing concepts such as the Test Pyramid to quickly capture bugs and reduce the cost of fixing them.

Some of the greatest inventions have come out of failures, it should be in your interest to fail quickly. Your future self may thank you.

Mo

I am a passionate tester, father, husband and gamer. I love to write blogs about Software Testing and generally contribute back to the Software Testing world.

More Posts - Twitter - Facebook

Published by

Mo

I am a passionate tester, father, husband and gamer. I love to write blogs about Software Testing and generally contribute back to the Software Testing world.