Любая продажа идеи начинается с фиксации выгоды для каждой из сторон. Поэтому я предлагаю выделить выгода получателей и в чем конкретно для них польза.

Менеджер продукта/руководитель команды разработки - меньше переживают, что если QA уйдет с проекта/заболеет или количество задач увеличится, то планы по проекту съедут и дедлайны не будут соблюдены - заинтересованы т.к с внедрением dev-testа снижается время тестирования и соответственно TTM Разработчики: - начинают лучше понимать конченый продукт, за счет чего формируют у себя продуктовый майндcет, который дает возможность расти дальше по карьерной лестнице - раньше получают обратную связь о своих изменений т.к могут прямо в процессе написания кода сразу его и тестить QA: - получают ресурсы, которые могут направить на более стратегически важные задачи, например для улучшения процессов обеспечения качества в команде или разработку инструментов для оптимизации затрат на тестирование

Какие могут быть возражения: “Не понимаю как развитие продуктового майндсета поможет мне вырасти” Ответ: Конечной целью любой it-компании является разработка продукта и заработка на нем. Бизнесу не нужен код в голом виде, только если он решает поставленную задачу. Понимание этого говорит нам о том, что продуктовый майндсет стоит во главе всего. Компаниям нужны разработчики, которы не просто пишут код а решают реальные задачи. Нужны тим.лиды, которые понимают ценность каждой из задач и могут легко валидировать приоритеты и за счет этого гибко взаимодействовать с бизнесом. В конечном счете нужна команда, которая не просто берет задачу и делает, но и челленджит ее продуктовую ценность и дает развернутый фидбек а так же предлагает подходящие альтернативы.

“Зачем тогда нам нужен QA, если мы сами все тестируем?” Ответ: работа QA заключается далеко не только в тестировании, мы работаем над улучшением процессов обеспечения качества как таковых (обеспечении более понятных и реализуемых требований, разрабатываем инструменты для тестирования и улучшаем testing experience как таковой). Так же при внедрении данной практики QA в любом случае будет нужен как центр экспертизы, который поможет команде вкатиться в основные моменты и даст консультации при каких-либо трудностях.

В заключение хочу сказать, что все это не про то, чтобы свалить все тестирование на разработку и уйти в закат. QA так же продолжает заниматься тестированием, у нас лишь появляется возможность при наличии других более стратегически важных задач в области обеспечения качества или при нехватке ресурсов на тестирование получить их путем привлечения других участников команды.

В следующий раз я постараюсь рассказать как конкретно можно подойти к внедрению данной практики в команде.