Могу сказать, что такой подход вполне возможен. Вот только зависит он от нескольких факторов.
Вариант, если в команде два и меньше автоматизатора:
Самые важные из которых, прозвучали в докладе.
1. Первое и основное – это хорошая коммуникация между разработчиками и тестировщиками:
a. Разработчик должен учитывать ваши пожелания по поводу технических деталей, таких как id элементов и более простая структура страницы
b. Вам должно быть легко, общаться с разработчиками приложения. Хорошо, если это одна команда, в лучших традициях Scrum, сидящая в одной комнате.
c. Вы должны быть в курсе технических деталей и планов разработки.
2. Разработчикам должна быть выгодна автоматизация тестирования. Как? Все зависит от проекта. На некоторых проектах чем больше багов пофиксил разработчик – тем лучше, ведь сколько работы-то проделано. В других ситуациях, разработчики стремятся уменьшить количество багов после сдачи в тестирование. Тут они не только сами тестируют свой код, но и могут помочь в разработке приёмочных тестов. И ведь исключительно в своих интересах, просто чтобы быть уверенным, что код работает.
3. Разработчики должны писать, править и понимать результаты прогона приёмочных авто тестов. Логи автоматизации понятны. Разобраться почему «элемент не найден» – не лень.
В таком режиме, сами разработчики смогут писать тесты перед реализацией функционала. С учетом этого, они будут заинтересованы в создании более простой верстки страницы и более тестируемого функционала.
С учетом такой слаженной работы – использование техники создания тестов перед реализацией фичи более чем реально.
Но, как вы понимаете, организация такой слаженности требует усилий. И усилий не только тестировщиков, но и разработчиков и менеджмента. И такие проекты не редкость. Но, есть и множество других проектов, в которых команда распределена, разработчики не видят общей цели, менеджмент не понимает зачем нужна автоматизация и какую выгоду она приносит. А может быть автоматизируются не те вещи, которые должны быть автоматизированы?
Команда из трех и больше автоматизаторов – это полноценная проектная команда. Вместе они уже наработали фреймворк для автоматизации, могут распределить обязанности: сегодня один пишет новые тесты, один фиксит id-элементов, один – отвечает за запуск тестов.
Наработав фреймворк по автоматизации, написать тесты перед появлением функционала вполне также реально. И постоянное вовличение разработчиков тут необязательно. Ведь еже есть функции, которые упрощают создание тестовых последовательностей. В принципе ясно, как мы будет проверять новый функционал, ведь по большей части, тесты будут состоять из действий над старым и уже давно автоматизированном функционалом. Единственное – нужно добавить новые проверки.
В таком режиме, с учетом уже развитого фреймворка – на мой взгляд, создание тестов перед добавлением нового функционала также вполне реально.
Но, стоит заметить, что для создания такого фреймворка автоматизации у вас должно быть либо достаточно времени для набивания собственных шишек и возможного переписывания самого фреймворка несколько раз, либо опытный человек, который мог бы изначально разработать хороший фреймворк.
Если разработчикам непонятно что делает автоматизация, менеджеры до сих пор не могут понять что это такое и зачем оно нужно, и вообще автоматизацией занимается даже не отдельный человек, а мануальный тестировщик, который не разбирается в программировании хотя бы на уровне Junior Developer и может потратить лишь 2 часа в день… в этом случае уж извините…
testomat.io управление авто тестами