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.

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.

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!

Why do you test? Is is because you want to prevent errors on a deployment affecting the visitor? Is it because you simply want to know that the software does what it needs to do? Or maybe you want to get to know the software a bit better?

Hopefully, in this day and age, your main software tests are automated. Running before a commit, running in the deployment pipeline and running on a testing environment. Repetitive jobs need automation and testing fits that mantra very well. This article is relevant for automated testing, although for certain topics you could use a manual testing perspective as well. If you like.