При многих преимуществах BDD, при её использовании команда может столкнуться со множестом проблем. Они могут варьироваться от простого нежелания всех членов команды вовлекаться в процесс до неудобства использования тестового фреймворка.
В докладе будут рассмотрены причины по которым BDD может не взлететь на проекте и возможные пути решения возникающих проблем. Также поговорим о том, почему важно привлекать всех членов QA команды к созданию автотестов и чем должен обладать тестовый фреймворк чтобы его использование было для понятным и удобным для всех участников процесса.
Доклад будет интересен для людей, которые хотят познакомиться с возможно новыми для себя путями построения процессов автоматизированного тестирования, в которых могут участвовать как manual так и automation QA.

Признайтесь, когда вы слышите выражение “паттерны проектирования”, первое, что приходит вам в голову: “Это что-то про код”. Это нормально. Особенно, если вы большую часть времени тестируете черным ящиком.Но однажды вы решаете, что вам нужны автотесты, и просите разработчиков помочь. Они смотрят на вашу тестовую документацию и… разводят руками: “Мы не можем по ней автоматизировать. Нарушены SRP, DRY, KISS. И вообще, как вы сами в этом разбираетесь?!”Выходит, что шаблоны проектирования применимы к тестовой документации. А вот каким образом, мы с вами и будем разбираться.Я постараюсь объяснить, какие выгоды дают паттерны и какие риски в себе несут. На примере документации нашего проекта покажу эволюцию в подходе к тест-дизайну. Бонусом поделюсь опытом применения хорошо задизайненного тестового проекта в целях масштабирования и вовлечения разработчиков в религию UI-тестирования. Поэтому доклад будет полезен любому QA: от junior до лида по качеству.