Lessons Learned Running a Successful Software Testing Meetup

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.

This post aims to share some of our learning

Liverpool Tester Gathering Logo
Continue reading “Lessons Learned Running a Successful Software Testing Meetup”

The Orchestra – Different Parts, Same Outcome

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

Continue reading “The Orchestra – Different Parts, Same Outcome”

Dissecting The Testing Quadrants – Rectangles

This is the first post attempting to document some of the conversation James Bach & I had whilst trying to determine what my understanding  of the Agile test quadrants actually was.

This post is a WIP as I’m sure I’ll be updating it as I walk through each of the quadrants & work with some of the different ideas & terminology we discussed.

Continue reading “Dissecting The Testing Quadrants – Rectangles”

Dissecting The Testing Quadrants

I’m a fan of the (Agile) Testing Quadrants, first described by Brian Marick back in 2003 as a matrix & later popularised by Lisa Crispin & Janet Gregory.

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.

BgYv9qMCEAAZURx.png large Continue reading “Dissecting The Testing Quadrants”

Hexagonal Architecture For Testers: Part 1

This post is WIP & under iterative development!

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.

table & chairs representing hexagonal architecture
Continue reading “Hexagonal Architecture For Testers: Part 1”