Conway’s Law for Test Automation?

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Melvin E. Conway via Wikipedia

Conway’s law continues to be one of the hard truths in IT deliveries. It tells us that solutions are shaped – by the shape of the delivery organization. While Conway’s law is usually seen on a macro level (Just Eat UK is an example) – it also applies to smaller units (see the Angel of North anti-pattern).

As software test automation becomes more and more like a software development project – I would hypothesize that Conway’s law indeed predicts the shape of the (test) automation solution. So in other words, if the shape of your automation is a pyramid/triangle, so is your team structure heavy on development tests.

A Prediction

Recently at Test Bash Home 2021 the test automation pyramid came up again as one on the inherent controversies in testing. During the “Ask Me Anything – The Future of Test Automation” with Alan Page, they predicted:

As 1) Developers do more test automation and 2) low-code tools become the de-facto standard for test automation. Based on these two trends test automation will trend to the shape of the pyramid based on better designed products.

Alan Page, Test Bash Home 2021 (my transcription)

I agree to the two first points. Though with the addition to the first point, that I have mapped where testers play an active part. And add tot the second point that Low code outmaneuvers classic coding styles across the board. Low-code tooling improves deliveries for both Testers, Developers and the business SME’s.

But as low code solutions become more specialized so does the visual code become like classic code – thus needing computer science disciplines like version control, trunk-based development, component breakdowns etc. And by the end of the day, so does all software test automation projects – they become computer engineering activities. And they align with the 24 Key Capabilities To Drive Improvement In Software Delivery.

But is the test automation pyramid necessary the trending outcome. I had to noodle some more. Thus the question to the Scale Test Automation with Your Developers in Mind panel, that also had to consider the topic.

Pro/Con

For classic software development projects – yes, add the test automation code to the development activity. But perhaps the trend in that space is more a microservices or server-less profile (Just Eat UK is an example), than classic feature heavy deliveries. Similar shapes and forms I would eventually expect to see in test automation projects.

Conway’s Law predict the shape of the solution based on the shape of the organization. Sometimes Conway’s law is something we have to beat to deliver better solutions – this can be done using Team Topologies (Reverse/inverse Conway) and architecture strategies using Wardley mapping. Conway’s law is in it self a prediction – not a path to “better designed products“.

“We shape our tools and, thereafter, our tools shape us.”

John Culkin (1967)

Especially in the context of low-code test automation projects we have to consider that there might not be both a developer, a tester and a business person in the loop. When we consider Test Automation for Software-as-a-Service Solutions – there might only be two persons or even just one person involved in the delivery of features. And since those are primarily GUI-based / low-code – the assumptions of the Test Automation Pyramid doesn’t hold. In those situations the delivery team works in a more coherent and nuclear mode – with fast feedback cycles.