Skip to main content


Showing posts from 2018

Overcome painful dependencies with improved adjacent testability

We had done it: We had built a testable system. We achieved high observability through monitoring, logging and alerting. We instituted controllability by using feature flags. We understood the build through pairing and cross-discipline-generated acceptance test automation. We aimed for decomposability by using small, well-formed services. But our pipeline was still failing — and failing often.

So what went wrong?

We had a horrible external dependency. Their service suffered from frequent downtime, and slow recovery times. Most painful was the fact that test data creation required testers to create a manual request through a ticketing system. We were dependent on a system with low testability, which undermined our own testability. And this had consequences for our flow of work to our customers. 

In this article, I will cover how to address such dependencies and engage with the teams that maintain them, including:

Enhanced observability by adding key events from your dependencies to your ow…

Going beyond "how are we going to test this?"

Testability is a really important topic for the future of testing. So much so that I believe that it's a really, really strong area for a tester to diversify into to remain relevant and have a major impact in an organisation. After all testability is for every discipline. If you said your mission was to build loosely coupled, observable, controllable and understandable systems, I know a few operations people from my past would have bitten both my hands off. Bringing various disciplines together is what a focus on testability can do.

It begins with powerful questions when it matters, in a feature inception or story kick off session. Asking this question can be really powerful:

How are we going to test this?
Its a great question, it has the "we" in there, which is a key part as an actor within a cross functional team. It also opens up the debate on the efficacy of testing on the thing that is about to be built, what types of testing are appropriate and enhancements needed to …

Why do Testers become Scrum Masters?

It was late and I was stuck on a train, so I pondered on the question of why do testers often (in my experience) become Scrum Masters. Its a very dear question to me, as its been a big part of my career journey In fact, I've been there and back again. Tester to supposed-to-be-testing-but-being-a-Scrum-Master to Scrum Master, back to Tester and very happy thank you.

I encapsulated my reasoning in the following:
Long train delay, decided to think about a thing. :) Why do testers (in my world anyway) often become Scrum Masters? — Ash Winter (@northern_tester) February 13, 2018The tweet got a lot of traction, and generated a couple of interesting threads which made me think.
Great list. Personally I think that as a scrum master I can add even more towards the goal of quality. — Christian Kram (@chr_kram) February 13, 2018 Perhaps part of the reason for the transition is a growing appreciation of where quality has its roots? If testing i…