Let's talk about T-shaped specialists. What does it mean? The idea is that as a professional, you can either go deep or you can go wide.
Say you're a junior working on the backend, and you can do some simple stuff like writing controllers or writing from JSON into a database. As you accumulate experience and learn in your field, your knowledge profile will deepen, and you will learn more about architecture, different design principles, databases, scaling, etc. We can dub this person a "scientist", someone who digs deep into their own field, an I-shaped specialist.
If yours is a typical team, you'll have a frontend developer and a tester beside you. Another direction for your professional growth is understanding more about their fields - basic stuff about forms and requests or how to write simple tests. Here, you go for width, not depth; you're a "sage", a dash-shaped specialist.
The T-shape
A functioning enterprise will require people to develop in both directions. Understanding SOLID principles is important for a developer, but so is writing unit tests, and the two are related. Going both deep and wide means you'll be T-shaped, which is very valuable today.
The direction of width helps with communication and understanding the general goals of the enterprise - which is why it is vital for business owners. However, they aren't the only ones that need it.
If people from different teams have trouble talking to each other, the cost of communicating will be real high, especially the cost of communicating goals. Everyone is going to hear things their own way, there will be misinterpretation, no understanding of what the definition of done is, etc. Or you can go into so much detail that tests requiring 30 minutes of work will have a specification that takes testers 3 hours to go through. Of course, the cost of not communicating goals will be even higher.
Silos
It's about the problem of silos. People either work in the context of business needs or the more narrow focus of their own fields; the distribution of effort is different in either case (you can see it e. g. in the metrics they use). And if each team is holed up in their own domain, all the communication will go through the manager, who will be constantly swamped.
This is what the three amigos approach is trying to solve, with the simple idea that we'd understand what we need to do better if we'd just bloody talked to each other once in a while. This is corroborated by research that shows transdisciplinary teams have an advantage when tackling "wicked problems" - problems that lack precise definitions, stopping rules, or opportunities for trial and error.
Building communication APIs
So, how do you get there? You need communication APIs, your shared boundaries with other specialists. There are many ways to share your expertise: meetings, code reviews, or just having a beer with colleagues. One of the most effective ways is a report.
If we go with the metaphor, what does an API do? It tells a person from the outside what something complicated will spit out from its insides; it's a common context for the inside and the outside. This is what a report does: condenses knowledge so that people with different backgrounds can talk about it. It creates a common context.
Reports are a universal thing that you can build yourself. Swagger is an excellent thing for that purpose - with language-independent documentation for APIs, it has the kind of common context we're talking about. You could build a report to compare two swaggers, one for tests and one for APIs, to tell you your test coverage - and that would be excellent common ground for testers and backend developers to meet each other.
Allure Report
Another great base for a report is an automated test. For the three amigos concept, automated acceptance tests provide a common expression of what we want from the system. But here, let's talk about test reports as a common context for different developers.
Today, having a tech stack with multiple languages talking to each other is perfectly common - like, Go, Python, Java on the backend, JavaScript on the frontend. With such a pipeline, it gets really difficult to figure out the causes of failures - you need to dig into different reports for different languages, and it all becomes a tangled mess in your head.
Here's where Allure Report comes in. It integrates with pretty much anything you can think of. Tests from every framework in every language all get transformed into the same data format. This base is used to display your test results in all kinds of neat ways.
Every test gets a representation in plain natural language, which doesn't depend on the framework:
This has everything you need to analyze the cause of failure - steps you can read without knowing the programming language, screenshots, and HTML of the page under test. Failed tests also include stack traces:
And there are also graphs based on aggregated data from your test results:
This stuff creates a common entry point for testing between people working with very different tools.
Conclusion
If you want effective lines of communication across professional boundaries, you need some common ground, something for people to talk about. Reports are great for this - they condense complex information so that anyone can read and understand it. And as people get the horizontal part of their T shape stronger, the costs of communication fall and organizational goals become much clearer for everybody.
