Thread by @JitGo

What I’ve learned from trying to build quality in rather then inspecting for it

A thread 👉🧵

#testing #testability #collaboration #automation #DEVCommunity #PsychologicalSafety

1\ when I started out in testing it was all about find the bugs and find them fast. Testers where typically another department to engineering. It was pretty much they build it we destroy it.

2\ This is what inspecting for quality is. You look for the issues at the end of the development process. It worked pretty well when you had an army of testers and no way to push out bug fixes other then sending people disks with patches in the post

3\ but then the internet and agile thing happened and everything changed.

Software could be updated easier and we started to work in multidisciplinary teams. We even met the people who came up with the ideas and used the software

4\ but we kept working as we did. They build it we destroy it.

We just told it to their faces now

5\ eventually people started to think this wasn’t very efficient maybe we could do it better?

Let’s automate the testing!

6\ Automate all the tests resulted in lots and lots of fragile, automated, end-to-end, UI tests.

Which worked sometimes and not others so needed full time testers to keep them running.

But we still had bugs the automated tests didn’t catch

7\So we now had a load of automated tests but still needed to do the manual testing.

One good thing that did come out of this was people started to see testers didn’t just button bash. They did something much more valuable: Exploratory testing!

8\ What exploratory testing showed was that the system can work how we might want it to work. But if you tried something that maybe you hadn’t anticipated a user to do it might fail.

Some time in small ways sometimes in major ways but the automated testing wouldn’t pick this up

9\ Automated testing only picked up what you told it to pick up. Otherwise it would walk right by oblivious to the fact that something didn’t work right.

10\ But automated UI testing and exploratory testing both still inspected for quality at the end.

We were still building bugs into the system. We need a way to build quality into process

11\ As Deming said, inspecting for quality is too late, the quality is already in the product

deming.org/inspection-is-…

12\ So how do we build quality in? Through #testability. Which is about reducing the uncertainty introduced when you make a changes to your system.

13\ how do you reduce the uncertainty?

By writing tests that check the *behaviour* of your system not implementation details

14\ A good way to think about these tests are PUMAs

Prove core behaviour,
Understood by all in the team,
Mandatory to be part of the build pipeline and
Automated

Which helps keep them focused and contributes towards reducing that uncertainty

15\ and just like Pumas, they need to be fast, really fast.

So UI tests are probably not ideal, including screenshot tests.

Which means there's limited overhead in running them. Helps to reduce uncertainty further

16\ PUMA tests should be written at the code level, preferably before any UI and focused on *your code*, not third party dependencies

17\ With tests focused on just your code, when they fail, you know it’s your code that’s changed.

Reducing uncertainty further

18\ how many tests well that depends on how many you need to Prove core behaviour and where the boundaries of your system exists

19\ Who should write the tests? The people that stand to gain the most from them.

Which is usually the developers.

20\ but that’s not to say testers and other disciplines can’t be involved.

The more you share what the tests do and don’t cover the better your uncertainty reduction for the team.

21\ but this needs leadership to happen.

You need to help people collaborate, share what they don’t know, mistakes they’ve made and generally learning from failure. Not covering up mistakes and misunderstandings

22\ the writing tests parts is almost the easy bit.

It’s the working together effectively that’s hard.

23\ that why I think so few teams manage to get towards testability.

Inspecting for quality is so much easier as you don’t really need to collaborate.

Everyone can just do their bit and pass the work onto the next person

24\ So how do we collaborate more effectively? With leadership that fosters psychological safety infoq.com/articles/testa…

If you found this thread helpful, then give it a retweet as others might too 😸

👉 🧵

https://twitter.com/JitGo/status/1588081807899168771