DEV Community: Robert Ecker

The Problem With High Test Coverage

Robert Ecker — Mon, 27 Nov 2017 08:23:54 +0000

Last week I attended Dan North’s workshop “Testing Faster”. Dan North is the originator of the term Behavior Driven Development (BDD). The whole workshop was amazing but there was one thing which really surprised me. Since BDD is basically another way of Test Driven Development (TDD), I would have expected that having a high test coverage was one of Dan’s goals when writing software. But what I learned was that he actually doesn’t care about the overall test coverage. He explained that in a very convincing way. In this article I wrote down what I learned about the test coverage.

The Meaning of Test Coverage

The test coverage (also known as code coverage) is a number which tells you how much of your production code is covered by automated tests. If you don’t have any automated tests you have a test coverage of 0%. If every single line of your production code is executed by at least one automated test you have a coverage of 100%. Having a high number might feel great but even 100% doesn’t mean that there are no bugs in your code. It only tells you whether the use cases which you have written tests for are working as expected or not.

The Cost of Testing

Automated tests can save you a lot of money! They can detect bugs before they are deployed to the production system which can prevent big damage. They can also help you to design your code in a way that makes it easy to maintain and extend in the future. But writing tests is not for free. It takes time and that time could also be spent on other things. Dan calls it the opportunity costs. Don’t get me wrong on this point. I don’t say that tests are a bad idea. They are not. In fact, they can be very important. But I want to encourage you to think about what makes sense to test and what not.

The Risk Plane

So how do we decide what to test? Imagine a software system which looks like this:

There are many components and dependencies between them. Now let’s add a coordinate system to the graph. The more a component is on the right side of the graph the more likely it is to break. The more impact a failure in a certain component would have the higher we draw it on the vertical axis. Let’s take a look at the risk plane:

Now imagine that the test coverage of our system is 80%. Sounds like quite a good number. But look at the component on the top right corner. It is very likely that something will break in that component and the impact of a failure would be very high. Having that in mind, 80% is actually quite low for that part. On the other hand: The component on the lower left corner is very unlikely to break. And even if it breaks the impact will be low. So does it really make sense to spend so much time on testing this component in order to keep the test coverage high? Wouldn’t it be more useful to spend our time on writing tests for the components on the upper right corner or even to build new features? Every hour we spend on coding means money invested by our company. It is our responsibility as software developers to make reasonable decisions on how to spend that money.

The Stakeholder Planes

Dan North says, “The goal of testing is to increase the confidence for stakeholders through evidence”. Evidence can be provided by our tests. Increasing doesn’t necessarily mean to reach the 100%. It requires some pragmatism to decide how much effort to spend in which situation. And who are the persons we are doing that for? It’s the stakeholders! It is not enough to tell them that we are great developers and everything is going to be alright. We should give them evidence. They should know which behavior is assured by tests. Developers tend to have a blind spot. Most developers think that their code is great and works. But the stakeholders do usually not have that much confidence in the developers which is why they need the evidence.

Often there are many kinds of stakeholders. They can be users, people from the security department, the customer support and many others. We can build software which is very unlikely to fail but if it is illegal we still cannot ship it. This is why we have to extend our model with another axis. We have to add planes for our stakeholders:

Usually, the stakeholders see the software from different perspectives. Sometimes aspects that you didn’t even think about are essential to them. Maybe it is extremely important that certain user roles must not access certain data. That would require a bigger testing effort. Talking to all kinds of your stakeholders is very helpful. Ask them what is the most important thing that you should concentrate on. On which part would they spend the most effort. If you do that with every stakeholder you will get a good idea of where to draw your components in the risk planes and how much testing effort to put on which component.

The Pragmatic Way

What Dan North made really clear to me is that the test coverage doesn’t tell much about the quality of the software. 80% can be too little for one component and it can be a waste of time for another component. When we write code we should first understand our stakeholders. What is really important? We should estimate the impact and the likelihood of potential bugs and pragmatically decide how much effort to spend on which component. We have to keep in mind that we are paid for our work. Every hour that we spend on coding costs money. It’s our responsibility as professional software developers to spend that money wisely.

This article was first published on team-coder.com.

A Good Manager Is Like a Gardener

Robert Ecker — Thu, 10 Aug 2017 20:31:37 +0000

Since I attended a Management 3.0 workshop a couple of weeks ago there is one thing that I cannot get out of my mind. It was a simple metaphor: A good manager is like a gardener. Imagine a garden full of vegetables, fruits and other plants. The gardener’s job is to create as much value as possible out of the garden. Value might be the fruits that the plants create. The more tomatoes, strawberries and potatoes grow the more value comes out of the garden.

What can the gardener do to create more value? Would it be helpful to go to the tomato plant and tell it to grow faster? To create more tomatoes? Definitely not. Are there any benefits the gardener should offer the tomato plant for growing faster? I don’t think so. But what can the gardener do? He can change the environment. He can create an optimal environment for the tomato plant and all the other plants to grow and create fruits. The gardener can give them water, maybe also a little bit of fertilizer. He can rearrange the plants if he realises that two of them have a bad influence on each other. Maybe one of them is too dominant and represses the other one. He can also protect the plants from too much direct sun light by creating some shadow areas.

In my opinion, a good manager should do what a gardener would do: Not telling his people what to do but helping them to grow. Creating an environment where everybody is save and where everybody can improve, be productive and be happy.

Give Up Perfection!

Robert Ecker — Tue, 04 Jul 2017 20:57:21 +0000

I wanted to write about that topic for weeks or maybe even months. But I never started. Until now! Something was holding me back from writing this article. It was almost like a fear. Maybe the fear of not being good enough. I was not sure what exactly to write down and how to write it. I didn’t even come up with a good title for that article and without a great title I didn’t want to start writing at all. The title has to be short and crispy. It has to catch the reader’s attention! It has to seem relevant to search engines. It has to be as perfect as the whole content of the article.

This desire for perfection is the reason why I have never published this article. It is the reason why instead of an interesting blog post, that could have inspired at least a few people, I have released nothing. But today all of a sudden it became crystal clear to me! There is no perfection. Life is so complex, there are so many possible solutions for every problem. What I like somebody else might hate and what I don’t like could be a life-changing inspiration for somebody else.

I don’t want to strive for perfection anymore. I want to actually get stuff done. I want to sing out loud even if I’m not a perfect singer. I want to release that feature to the customers even if it is not perfect, yet. I want to tell my opinion even if not everybody at the table will agree. And I finally want to publish this blog post even if it is not perfect.

I didn’t want to release the last article I wrote without letting a native English speaking friend of me having a look on it. I was afraid that there might be a grammar mistake in my text. That would be fatal because it would make the whole blog post imperfect! People might think that I’m not a professional! Bullshit! Maybe some people would realize that I’m not a native speaker of the English language but does that make me any less reliable on the topic I write about? I don’t think so! In fact, there are professionals who’s native language is obviously not English and I still look up to them and admire them for being so professional.

I guess there are certain areas where perfection would indeed be a desirable goal. Like in nuclear power stations, in space missions or in certain medical fields. But for writing a blog post? Come on! Seriously, the important thing in a blog post is the basic idea behind it. Not that every word is perfect. And I think that this applies to most things in life. The ideas are important. The messages you want to tell. The feelings that you want to share and the actual things that are important to you.

Perfection is a nice direction but it’s not a goal that must be reached. It can motivate you to get better but you should never let you pull down by the unachievable illusion that everything must be perfect.

Someone once told me that the perfect blog post has about 1500 words. That would mean that I have about 1000 words to go. Guess what? This will be the last paragraph and it feels great! I will stop here and just call this article „Give Up Perfection!“. Even if this article is not perfect I hope that I could make my message clear. There is no perfection and even if there was something like that we usually wouldn’t need it. Instead we should concentrate on the really important stuff and just do it!

The Power of Fluid Teams

Robert Ecker — Thu, 23 Feb 2017 22:47:06 +0000

Do you know this exciting feeling when you work on your own side project? The incredible motivation when you work on it and this magical feeling when you publish it! What is the difference between those kind of projects and the projects you are working on at work? I think the most relevant difference is that most people do what they are told to do at work instead of what they would love to do.

Imagine a working environment where nobody tells you what to work on! How great would it be if you could work on what you really believe in! If you could talk to colleagues about your ideas and everybody who truly believes in it would join you. Teams would be fluid! They would form spontaneously and exist until the work is done. Then you could join another team that convinces you.

What do you think how productive this would be? I think the potential would be amazing! Features would be developed so much quicker and with so much love!

The question is what would happen with the tasks that nobody wants to do? Maybe, if nobody wants them done, it is not so important. If something doesn't excite anybody from the company, maybe it also doesn't excite most of the users.

I would like to try it out but it's hard to convince a company to give up all the control and hope that everything will be fine. I read that Valve, a software company from the United States, did it very successfully. Have you any experiences with experiments like that? I would love to hear about it!

Hi, I'm Robert MiÃŸbach

Robert Ecker — Thu, 23 Feb 2017 07:59:30 +0000

I have been coding for 15 years.

You can find me on Twitter as @teamcoder_

I live in Constance, Germany.

I mostly program in these languages: Swift, Objective-C.

I am currently learning more about Python.

Nice to meet you, I hope we can have some interesting discussions :)