After nearly 3 years & 16 Liverpool Tester Gatherings, the 3 of us have learned several very valuable lessons in running free meetups to provide a platform for new & experienced speakers, with both local & international testing status.
I typically use the metaphor of an orchestra with Testers across different teams/products/squads within an organisation to help the understanding of how different testers can offer value within their teams.
The idea being that the argument “I test websites & they test data” is redundant when you’re thinking of the product or system as a whole
This is the 3rd in a series of posts where I dig into the Agile Testing Quadrants after a coaching session I had with James Bach. This post focuses on the left & right sides of the matrix; the columns.
James Bach helped me to break down the quadrants in order to get a deeper understanding of what each quadrant meant. It was during this conversation I realised I had a very shallow understanding of the model & I was effectively diluting (& even twisting?!) the message the quadrants were trying to get across.
At my current client, we’re being coached in the Hexagonal Architecture pattern.
Admittedly, the primary focus is towards the Programmers, but the change in the development strategy has an impact on us Testers so we get a seat a table.
What is this change in the development strategy which will impact us Testers? The pattern considers integration tests as brittle & unneccessarily linking the business logic to the implementation. As such, with this pattern, you want as few integration tests as possible. So the question is:
As a Tester, how confident am I that the removal of (automated) integration tests have not decreased the stability of the code?
In this 3 part series, I hope to learn more about hexagonal architecture, what it does for the teams test strategy & what the impact is for Testers.