Having identified a number of different types of tests, you can already imagine that each tests has its own place in the process.

The process here is key: because software development is complex and consists of several steps, it just makes sense to validate each of these steps. We'll outline a lineair process, but of course in practice there's more iteration between steps. That's fine and is in fact where tests offer the confidence of moving back and forth!

Software development is complex. It involves people talking about an idea or concept and then translating it to code. The code then is compiled, packages or run and we expect a certain result. In all of these (generic) steps, there's room for complexity, interpretation and errors to sneak into the software.

Luckily, testing software has matured and expanded to a level where we can confidently release code that doesn't break on build, only changes where change is needed and the features can even be asserted before writing a single line of code!

When the year closes, it's always a good moment to reflect on the past years achievements to see the bigger picture. If I look back to my achievements, I am proud and grateful for all I've achieved with support of people around me.

A lot of things that have been in the works seemed to click this year and directed my career into a new path, more focussed on engaging people over code. Something that suits me at this point in my career.

I saw this post, by Erik Flowers while scrolling the LinkedIn feed which resonated with some thoughts that have been floating in my mind without anything to latch on to. But now those thought found something to root.

I am currently working as a "software engineer" (commonly also referred to as "frontend developer") and although I like to label myself more as an "interaction developer" my main domain consists of designing software architectures and writing code. My background has always involved some level of getting involved with the user experience (UX) aspect. And while that may seem something that sticks out, I feel it is both to build good software and unfortunately also something that is not commonplace.

I was seeing a lot of Playwright mentions in my timelines recently, so I decided to investigate what the fuss was all about. Playwright, as it turns out, is a tool for executing end to end (e2e) tests, similar to Cypress.

With Cypress being my go to tool to integrate e2e tests, I figured I could do a comparison on the two, to see which better fits my needs at this point.

When you're part of a "modern" software building team, changes are, it is being referred to as "multi disciplinary" or "cross functional". This is to indicate that the team is made up of backend developers, frontend developers, some design role(s) and maybe somebody in charge of metrics and KPIs or some additional, specialised roles.

The thought process here is that if you do that, the team can be completely in control of their responsibility (maybe add some DevOps terminology in there then, as well). Which makes for agile teams.

Before we dive into the topic, a little bit of context would be necessary because we're going to talk about a solution that works for our organisation. Having context helps you in deciding if and what would work in your situation.

So at the company I currently work for, we cater to a big audience. As a big company, we also have a big stake in IT solutions to get our businesses running. A lot of our software and tooling is build in house.

Nobody that I know of is happy with endless repetition. Software has drastically improved any field of work where repetition takes place by facilitating a certain level of automation to ease all of our jobs. But when you’re implementing any automated process, there’s always a cost to consider.

The good news when working on software, is that cost is relatively low compared to effort. Since we’re working in a landscape that’s so very tightly coupled to the tools that provide automation, most of the automating is a breeze!