Cypress - Dealing with flaky tests

Test automation is all about feedback. Feedback that gives you quality updates about the features your team has built. A continuous green build is always the goal because this should give you the confidence you need to go to production. Unfortunately, I’m more used to a “traffic light build”, a build which passes and fails intermittently, mainly because of flaky tests. That is one of the worst things about end to end testing in my opinion.

Why on earth do we still put software into production when we can’t trust our test automation?! Well, that's because we retry the build a couple of times until we have a lucky hit: the build is green and we’re ready to go to production. Although this is a solution, it still feels like a pretty silly thing to do.

Another option, which has my preference, is refactoring those tests until they actually work. The annoying part about this is that you don’t know what’s going on, and most of the time it is impossible to reproduce the failures. Reproducing them takes a lot of time debugging, analysing and mostly guessing where the problem is.

What if we could actually see what’s going on?

 Read more

Nomad 0.5 configuration templates: consul-template is dead! long live consul-template!

Bastiaan Bakker

Or... has Nomad made the Consul-template tool obsolete?

If you employ Consul or Vault to provide service discovery or secrets management to your applications you will love the freshly released 0.5 version of the Nomad workload scheduler: it includes a new 'template' feature to dynamically generate configuration files from Consul and Vault data for the jobs it runs. Bundling Consul-template as a sidecar to your application is no longer necessary.

Nomad, Consul and Consul-template

A year ago Nomad 0.2 added support for automatic registration of jobs in Consul via a service configuration block. However the applications themselves still had to handle reading data from Consul. For this you had the following three options: Read more

Better guesswork for Product Owners

Chris Lukassen

Estimation, if there is one concept hard to grasp in product development it will be when things are done. With done I don’t mean the releasable increment from the iteration, but rather what will be in it? or in Product Management speak: “what problem does it solve for our customer?”.

I increasingly am practicing randori (sparring matches in judo) and find it has increased my agile fu. It’s a constant adjustment of balance, creating opportunities rather than waiting for them to unfold, follow through fast or the opportunity we created is gone. It’s hard work, time boxed and most of the time I loose learn.

The key thing in both situations is that we don’t have a lot of time to estimate what will work or not. We can’t plan very far ahead and we have almost no data to make assumptions on, we do know however the extreme boundaries of the assumptions and iterate from there.

 Read more

Building on the shoulders of giants: microservices as a redesign strategy

Gideon de Kok

With the rise of new-IT backed companies in almost every segment; from retail to financial institutions, more traditional companies are often forced in change or perish strategies.

Where the business strengths of newer competitors are often enforced by strong, serial startup developers, able to integrate the experience of previous failures into completely new stacks. Older companies’ businesses often rely on legacy software, composed into monolithic software stacks, with a team morale pushing talent out of the companies faster then they can persuade new recruits.

As internet facing services are becoming the most crucial factor in a company’s business value, it’s becoming harder and harder for more traditional companies to keep up. Performance issues through the lack of elasticity in software stacks, lack of business flexibility through technical impediments and overall lack of agility through long development cycles.

And while a complete redesign or rebuild of underlying software stacks would probably be the best approach to gain back performance and overall developer satisfaction, it will carve a big chunk out of a company’s resources. Besides that, successfully redesigning a complete system in parallel with normal business stays a big bet.

A common interpretation of the strengths of microservices is formed around the idea of scalability: by sharding application logic into multiple smaller components, overall vertical and horizontal scalability can be improved were it hurts. And while elasticity is a trait which occurs when systems are composed of independent services. The true strengths of microservices go far deeper than runtime performance.

Continue reading on Medium.com

 

OMG They made me Product Owner!!

Chris Lukassen

The face of guy in the hallway expressed a mixture of euphoria and terror when I passed him in the hallway. We had met at the coffee machine before and we discussed how the company was moving to a more Scrum based way of developing their products.

Between euphoria and terror

Between euphoria and terror

“You sort of know how this PO thing works right?” was his first question. When I nodded he confined in me that they had made him Product Owner of a new team, without prior training. In general, not the best start, but I can see why the guys were anxious to start: their Product would address a pain experienced by many of their clients, promising start!

Over coffee and a whiteboard we came up with four steps you can take to kickstart a team that is new to Scrum and the Product Owner role.

 Read more

Robots bring business and IT together

Erik Zeedijk

Maybe you’ve already read the diary of one of our mBots, if not I encourage you to do so first! So, what was this day all about? How did we come to organise this and what did the participants learn?

Changing teams

As companies decide to adopt a more agile way of working, they also start to form multidisciplinary scrum teams. However, there still is a big challenge. When you work with several disciplines in your scrum team, you are exposed to the risk that you still create mini-handovers. First the business analyst will make the design, the developer(s) will build it, the testers will test it and if you’re lucky the business is happy in the end. Team members tend to keep doing what they’ve always been doing. Nothing really changed! Of course, we cannot realistically expect that the business suddenly starts programming, but it would be great if they know the difficulties that developers cope with. It works the same the other way around. We need to learn from each other and bring our work closer together. Read more

Guest blog: in response to "The Five Belts of the Product Owner

rey

This is a response to Chris Lukassen's excellent post titled, "The Five Belts of the Product Owner." If you haven't read it, my post won't make much sense, so go read it before you delve further into my post.

Chris's post brought up many thoughts and feelings because it hit the intersection of two of the things that are taking up much of my focus as of late, Judo and Product Management.
 Read more

A day in the life of an mbot

Maaike Brinkhof

xebiamaaiketesterblogstorymbotdef

Today, I managed to find a diary hidden on one of the mbots we have at the office. I couldn't see it in the user interface, but when I was doing some maintenance on the robot a simple 'ls -la' command in the terminal showed me this hidden content. It was so cute that I wouldn't want to keep it from you! The robot is writing about a workshop my colleagues and I facilitated for ING. Stay tuned for a report about this day written by an actual human: my colleague Erik Zeedijk.

Kind regards,

The test professor Read more

Being An Agile Security Officer

Dave van Stein

Whenever I give a presentation, training, or just talk to security teams, it becomes clear that over the years a gap has been created between application security and development. A gap we created consciously and with intent and that became painfully visible with the introduction of Agile and DevOps. Suddenly exhaustive information security policies with checklists and penetration tests became serious impediments. The challenge we are facing now is how to bridge this gap again.

Fortunately this challenge is easier to solve as it appears to be. The key to success is to split the security officer function more Agile minded roles with different responsibilities and duties. In the coming blogs I will dive deeper into the different aspects of these roles and the differences in the responsibilities and duties. But first we need to take a little trip down to memory lane to understand how we ended up in this situation.

 Read more

ISO/IEC 27001:2013 and Scrum 5 Ways to Make it Less Painful

Chris Lukassen

At some point, you get a nose for things that don’t feel right. Things that sound reasonable when explained, yet you get that gnawing feeling it sort of goes against nature. Working with Scrum and compliance to ISO is one of those things. Here are 5 ways to merge a rigid security standard, without violating Scrum values like focus, openness or its pillars, transparency, adaption and trust.

 Read more