Design Patterns are not only about program code but about test documentation too

Admit the fact, when you hear the phrase "design patterns", the first thing that comes to your mind is, "It's something about code." It's ok, especially if you spend most of your time testing with a black box. But one day, you decide you need autotests and ask the developers for help. They look at your test documentation and ... throw up their hands: “We can't automate with it. SRP, DRY, KISS patterns are violated here. And anyway, how do you figure it out for yourselves?!

It turns out that design patterns are applicable for test documentation. We'll try to figure out how exactly. 

I will try to explain what are the benefits and risks of patterns usage. I'll show the evolution in the test design approach on the example of our project documentation. As a bonus, I'll share my experience using a well-designed test project for scaling and engaging developers in the UI-testing religion. Therefore, the talk will be useful for any QA: from junior to QA Lead.