Why Integration Tests won’t save you… or your software

Did the title tease you? Great, job is done! Today I will tell you my story about Integration Tests; it came after another knowledge share lunch with my pal Kenny.

By this definition an Integration Test is

(…) the phase in software testing in which individual software modules are combined and tested as a group. Integration testing is conducted to evaluate the compliance of a system or component with specified functional requirements. It occurs after unit testing and before validation testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready forsystem testing.

Sounds pretty waterfall, right? It is! also, the implementation approaches that I observed creates huge dependencies between teams, coupling the software release process.

Read more →

EventStorming cheat sheet

EventStorming is the smartest approach to collaborate beyond silo boundaries. The power of EventStorming comes from a diverse multi-disciplined group of people who, together, have a lot of wisdom and knowledge. While it originally was invented for a workshop to model domain-driven design aggregates, it now has a broader spectrum. From gaining a big-picture problem space of the whole domain to gaining insight into the entire software delivery flow and creating a long term planning. Every one of these workshops has the same basic requirements and needs. In this EventStorming cheat sheet post, I will describe these basic requirements in a cheat sheet.

Read more →

Uncle Bob and my personal programming Kata

My first [Uncle Bob] event was the 2017 [GoTo conference] in Amsterdam, where Robert Martin delivered a talk like he must have done a thousand times. And many of you will probably have seen some version of it way back when. For me it was all new, having managed to somehow avoid the experience for years. He said many things that made sense to me at the time, but what got stuck in my head was the idea of a programming Kata. The advice I distilled from his words was to take a small programming problem and try to implement a solution over and over again. The actual solution would be less important than the act of solving the problem. Allowing you to experiment in a safe and well known environment. Small techniques for problem solving would gradually become part of muscle memory, much like happens, or so I’m led to believe, in martial arts.

I liked the idea and found myself a small problem: read more…

CertShout: All your domains are public

TLS should be mandatory for every website. But, when you set it up, make sure you configure the certificate correctly. This includes not having any sensitive data in any of the fields of the certificate. Because that certificate will become publicly available if you use a CA supporting Certificate Transparency. By Marinus Kuivenhoven and Jeroen Willemsen .

Read more →

Cultural needs designing bounded contexts

Without a doubt, the bounded context pattern from Eric Evans book domain-driven design is one of the more essential patterns for designing and building modern software. Especially in the land of microservices architectures, where setting proper bounded context which is highly linked with the business goals aka the domain is essential to not get into the distributed monolith anti-pattern. The bounded context is in its core a language boundary, a boundary where language can stay consistent and which is the boundary of the model designed for a purpose. Boundaries for people are crucial from a culture perspective. People cannot live without boundaries; it is a way in which we can define our self and separate us from the rest. To define our self creates an identity, a feeling of belonging which in time can create ownership. However, to be able to define our self, we must also define the others to keep our own identity. When we look at cultural anthropology, we traditionally did this on the border through get-togethers like marketplaces, where we exchange goods. Now if we want to keep the cultural benefits of the bounded context within our company, we must also take care of the cultural needs designing bounded contexts. In this post, I describe these culture needs when using the bounded context pattern.

Read more →

Frictionless checkouts for GAMMA and KARWEI

Over the years, Xebia has been the driver of Agile software development at Intergamma, known for the GAMMA and KARWEI DIY stores. A year ago, we set out to replace the checkout process for their webshops. The existing checkout was slow and cumbersome to use, and no longer on par with other parts of the website. We knew there was a lot of room for improvement. In order to justify the investment we needed measurable results quickly. Within a year, we’re consistently seeing a significant conversion rate improvement.

Before starting out to replace the checkout, we discussed the technology stack and general approach. We had prior experience with React and Next.js, but decided against Next.js because of the complexity it adds. A checkout app also doesn’t need to be indexed by search engines, which is why you’d otherwise want to use Next.js. We decided to stick with a standard React setup, which enables us to focus and keep things simple. In order to measure our success, we set up A/B testing to directly compare the old and new checkout running in parallel.

Read more →

Agile Chef

Agile Chef

As a real ‘Foody’ I love to spend hours in the kitchen and experimenting. I also watch a lot of TV shows and documentaries about food. The other day I was watching an episode on Michelin star Chef’s and this one was about Richard van Oostenbrugge. He recently received his first Michelin star in his own restaurant ‘212’ in Amsterdam.

While I was watching it suddenly struck me that Chef Richard and his team were actually working quite in an Agile way. ‘We take a dish and try to improve this again and again, instead of starting some new every time’. For me this is a great example of ‘Inspect’ and ‘Adapt’. Continuously and in small steps improve your product until it is perfect and worth of a Michelin star. If you have dinner in restaurant ‘212’ you can look from all tables straight into the kitchen. All the food is prepared right in front of you. For me a perfect example of ‘Transparency’.

Scrum Values

So, what about some of the Scrum values like courage, focus, commitment, respect and openness in a restaurant kitchen?

Without courage there will never evolve a new Michelin star worthy dish. It takes a lot of commitment to put in the needed work hours day in day out. You need a sharp focus on quality, preparing methods and ingredients to get and to keep your Michelin stars. All team members in the kitchen, from the dishwasher to the chef have a lot of respect for each other and they all need each other to deliver the perfect dish. And finally, there is lots of quick feedback amongst the team members, a sure sign of openness.

I really like the extreme focus of a Michelin star restaurant on the end product and to see all teams work close together. For the perfect end result and best customer experience you also need the ‘black brigade’ and they also need to be aligned perfectly.

All in all, I think a Michelin star restaurant (and a lot of other restaurants) are a perfect example of an Agile mindset. Next time you go out to a nice restaurant put on your Agile glasses and see what elements of their way of working you can use in your team or organization.


The 5 unit testing guidelines

A unit test is a small automated check. It checks a tiny bit of software. Unit tests can be written relatively easily and they run in a matter of milliseconds. They are commonly being triggered automatically when somebody submits code to a repository so that the quality of the software is being validated, automatically, before it’s deployed onto the production environment.

In reality, unit tests are often far from small. They’re often hard to maintain and it’s hard to understand what the code that’s being tested was supposed to do when a test fails. As a result, unit testing becomes a costly exercise that slows down the team and the test-results doesn’t really prove much.

Read more →

Share This