by Thierry de Pauw on
Testability is everyone's responsibility, Ash Winter @northern_tester
Your system is hard to test (I don't know you but it is true).
You have too much work in progress.
Your testers are at the sharp end (and you should feel bad about it).
If it's hard to test...
... it won't get tested.
... the tester will test it
... it won't work
... you will drive your ops people mad
... your team testing culture will be a distant dream
It's about time that testability became everyone's responsibility.
- smells of testability
- testable architecture is a leading indicator of quality
- power of operability
- maintaining the mission
What is that subtle yet overpowering smell ...
- release management theatre: introducing release testing because once something bad happened
- mono strategies: we test it like this
- teams looking for more testers
- hard to test dependencies
- ... and on and on ...
Testability is a #systemsthinking problem. @northern_tester
That'll be your system architecture ...
Get the right people in the room ... => get testers in the room to talk about testable architecture
20.000 transactions per second ...
Load testing at the end?
You must really know what you're doing => gogo meetings, will release it anyway, you'll be on-call
Monolith, monolith, monolith!!!
On-Call? I love on call! I'm being your quality proxy.
- Controllability: this is what everyone should talk about when talking about testability.
Can you say what it needed to be?
- Decomposability: the ability to isolate a component to test.
- Simplicity: keeping it simple.
- Observability: is a big thing for testing => monitoring and alerting you look at things you think will happen. Ask questions about your system. That's what we do as testers too.
- New services for high throughput APIs
- Retire unused API's
- Circuit breakers
- transition from logs to events
- tracing ID's
- feature toggle dashboard
- architectural decision records
- actionable alerts
Operability matters ...
Run book dialogue sheet by Matthew Skelton.
This is the most important artefact to start talking about testability with teams.
After some hard work ...
- a useful run book
- isolatable services for load testing
- less services to melt our brains
- ask questions of the system
- closer to production: one of the biggest testability gains
- more sleep, less stress
- better testing experience
This is all very nice but sales ...
cost of delay
=> predictability and known quality
testing debt => tech debt quadrant by @martinfowler
tests you trust
Sounds like a testers problem ...
- fast feedback
- less context switching
- build the right thing
Testers are often seen as responsible for testability.
Not alone. They need advocates.
It affects us all, especially our friends in operations.
Book by Ash Winter: