The feature testing development process is iterative

If after the first discussion of the feature something is wrong, the designer and the product simply leave for revision. They might tweak the layout a little or rethink the user script a little. After that, we meet again to discuss the new layout. If everyone is satisfied with everything, then the layout will go directly to development. If not, we can redo it and discuss it again.

Involving testers and the entire development team in general at the earliest stages is very beneficial for the process and the business as a whole. A simple rule works here: the earlier a defect or any problem is discovered, the cheaper it will be to fix it. If a defect is discovered at the stage of layouts in Figma or even within the framework of an idea, then it costs nothing to simply redraw or rethink it. But if a bug is discovered directly on the release or even after development, then fixing it is much more expensive.

Domain-Driven Design (DDD) in Software Testing

At that time, I was far from considering myself an expert in this field. However, my knowledge was enough to help the company minimize and even eliminate most of the problems in the processes of the development team.

Time goes by, but such problems do not disappear in companies, despite the fact that solutions to these problems exist and are not some kind of secret. Maybe people just don't know about these solutions. Perhaps old approaches such as GRASP (1997), SOLID (2000) or DDD (2003) have been forgotten or considered obsolete? This reminds me of a situation that happened in the dark ages, when the ancient knowledge was simply lost. The same thing happens with these old ideas: they are still relevant and can help solve current problems, but they are simply ignored. It's like we're living in the Dark Ages of development.