BDD part 1

1. The product owner (PO) has an idea. Here is a fancy portal for the customers
2. The PO converts the idea into a concept and hands it over to the dev team
3. Dev team develops a product based on the concept
4. The developers hand over the product to QA
5. Test manager (QA) reports bugs back to dev team. It goes on with3)so many times until the product is ready for acceptance
6. After a few cycles in QA, the product must finally be handed over to the PO for acceptance.
7. The PO finds his requirements not implemented and is correspondingly dissatisfied.

This process is so painful because only after the software has been developed can it be determined that not all project participants have the same picture of the software. The already developed software must be changed at great expense. The testing phase is always at risk of causing an explosion of effort.

The experience can be frustrating for all participants

• The test manager acts as the bearer of bad news, receiving negative feedback from the team even though he did a good job and is not responsible for the misunderstanding that occurred.
• The developers have done a good job. They point out how technically good the developed solution is. The stability of the software is symbolized in the picture by the bricks used. The developers now have to rebuild the software under time pressure, making compromises that they are not actually prepared to make.
• The product owner had actually expected to be able to accept a new functionality and put it into operation. He now has to accept that the development will take longer or be more expensive. He may also have to make technical compromises in order to save the work done and the success of the project.

Early feedback as a painkiller.

The described problem has occurred again and again in the history of software development and in countless forms. Many probably consider it a law of nature. Accordingly, there are a variety of strategies to avoid or at least alleviate this pain. Many of these strategies involve getting feedback as early as possible.

A classic technique to get early feedback during software development is test-driven-development (aka TDD). The developer writes the test first, then the actual software. The resulting unit tests thus first serve the development and from then on as regression tests. TDD is a core component of BDD as we will see later.

The most direct feedback is offered by Pair Programming where the developer gets feedback from his colleague while writing the code. See the articles by Guido (link) and Robert (link

Scrum & Co: Iterative Methods

Another strategy is to publish the result of the development as early as possible and as often as possible in order to be able to recognize an erroneous development as early as possible by the feedback of the testers and users. (http://en.wikipedia.org/wiki/Release_early,_release_often). A possibility this to convert is the development in iterations: Instead of developing a software project over months, then publishing and the feedback of the customer to wait, we divide the work into iterations.

Examples of iterative methods are the sprints in Scrum or the releases in Feature Based Programming After an iteration of maybe 2 or 3 weeks, a part of the software is published and released for testing and use.

In an iterative approach, the promise is that only work of one iteration length (e.g., 2 weeks) can go in the wrong direction. Accordingly, the above-described erroneous developments still exist. In particular, if one does not examine the project progress after each iteration accordingly exactly and test for regressions.

Following the same reasoning, months or years of work can be at risk in classic projects. In the worst case, it turns out that the requirements can no longer be met and a project fails.

Continuous Delivery as the next stage of evolution

The concept of Continuous Delivery, as we operate it at Otto, goes a big step further. Every commit of a developer can, in principle, go live. Ideally, this happens several times a day. In reality, maybe every 2 days. So instead of collecting the changes to the software over weeks and putting them live all at once, you try to do as many and as small deployments as possible. A nice side effect is that with each release, only a very small change goes live. If an error is discovered in a release, it can be narrowed down accordingly and corrected in a targeted manner. Even a rollback that may become necessary loses its horror and becomes easier to manage.

Continuous Delivery is a holistic approach and a highly complex task. One of the technical hurdles we had to overcome is described by Guido in his article about Blue-Green-Deployment one of the problems in development in his article about Feature Toggles (link).

Actually, however, you want to exclude errors in production before deployment. Continuous Delivery is therefore only possible if there is a high level of trust in the quality of the delivered software. This confidence can only be established by a suitable development process, and must be secured in this by automated tests.

There are two important requirements on the Build process, which must be fulfilled, before one can think of it at any time and often to be able to be deployed

1. Tests must verify, as far as possible, the complete behavior of the software. This must be true for any software release that is to go live.
2. The tests must have the shortest possible execution time so that the deployment process is not unnecessarily prolonged. Ideally, the execution time is so short that the complete test suite is run for each commit of a developer.

Behaviour Driven Development as lubricant

This is where Behaviour Driven Development comes into play. It makes two very important contributions

1. It creates trust of non-technical people in the work of developers. This is achieved by writing the functional tests to be automated in human-readable language. Each functional requirement is first implemented in an automated test. In this way, the behavior of the software checked by these tests is comprehensible to all project participants. This is what the second part of the series is about.
2. It enables the automated tests to be developed as efficiently and comprehensively as possible. It offers the developer with the test pyramid a method to develop a minimal test suite, which covers all functionalities of the software. This will be the subject of the third part.