Тесты должна писать разработка (?)
Дисклеймер: меня зовут Эрик Бурыгин, я давно работаю тестировщиком, веду студентов на курсе «Инженер по тестированию», поэтому может показаться, что тестировщик просто хочет перекинуть кусок работы на разработчиков. На самом деле у описываемого подхода есть как плюсы, так и минусы, поэтому статья носит в том числе и дискуссионный характер. Буду рад увидеть в комментах мнения как разработчиков, так и тестировщиков.
Если тесты пишет разработка, можно решить сразу несколько проблем, например:
- Ощутимо ускорить релизный цикл.
- Снять нагрузку с тестирования.
В большинстве команд процесс выглядит примерно так:
- Разработчик создаёт новые фичи и допиливает существующие.
- Тестировщик всё это тестирует и пишет различные тест-кейсы.
- Автоматизатор, оправдывая название должности, автоматизирует всё по написанным тест-кейсам из п.2.
Вроде бы всё выглядит просто.
Но в этой парадигме есть слабые места.
Допустим, разработчик доделал свою фичу и благополучно отдал её в тестирование. Но фича получилась не medium rare, а откровенно сырая. Это приведёт к переоткрытию задачи и дополнительным фиксам, причём итераций может быть от одной до N, в зависимости от размера этой фичи, её сложности, влияния на смежные процессы, добросовестности самого разработчика. А ещё от того, как у вас в принципе устроены процессы внутри разработки, насколько тщательно смотрятся пул-реквесты, запускается ли приложение перед отправкой на тестирование. 
В общем, переменных хватает.
После того как задача будет протестирована и готова к релизу, тестированию нужно написать на весь функционал тест-кейсы. Затем сделать регресс/смоук и наконец зарелизить.
Автоматизатор же после получения написанных тест-кейсов покрывает тестами функционал. Здесь есть довольно большая вероятность, что задача попадёт в существующую очередь, поэтому тесты будут написаны с задержкой.
— Просто нужно больше разработчиков
Увы, не панацея. Скорее наоборот. Чем больше в этой схеме у вас будет разработчиков, тем сильнее будет нагрузка на тестирование. В итоге будет увеличиваться или релизный цикл, или сама команда тестирования.
А это по принципу домино увеличит нагрузку уже на автоматизаторов, которым придётся обрабатывать всё большее и большее количество тест-кейсов, падающих на них от тестирования. Будет зеркальная ситуация: или увеличится время покрытия тестами, или штат автоматизаторов.
На восемь разработчиков обычно приходится два тестировщика и один автоматизатор. Автоматизация при этом не участвует в релизном цикле напрямую — скорее находится поблизости. И возникает вопрос: как сделать описанные процессы более эффективными, да ещё и не потерять в качестве?
Давайте попробуем сдвинуть этап автоматизации с третьего места на первое, на этап разработки.
Что получится
Получится сразу неплохой набор плюсов, смотрите:
- разработчики пишут тесты одновременно с написанием самой фичи, что существенно улучшает её качество;
- падает нагрузка на тестирование: тестировщикам теперь надо посмотреть результаты тестов и оценить, в достаточной ли степени задача покрыта тестами;
- ручного регресса в схеме больше нет за ненадобностью.
А что тестировщики?
Тестировщик и в обновлённой парадигме остаётся экспертом в тестировании — именно он ревьюит как качество, так и полноту покрытия автотестами той или иной фичи, а также занимается анализом сложных и необычных проблем. Но теперь, благодаря снижению нагрузки, у тестировщика освобождается часть времени, он может заниматься процессами.
При этом надо понимать, что ручное тестирование всё равно никуда не денется — у вас всегда будет что-то, что по какой-то причине автоматизировать либо невозможно, либо не имеет смысла.
Так вот, к новой парадигме. Круто же? Да хоть прямо сейчас внедрять. Если получится сделать две вещи.
- Продать эту идею разработке. Потому что далеко не каждый разработчик сразу захочет писать тесты, ведь это может быть скучно, или он просто не хочет: у вас, вообще-то, тестировщики вон там для чего сидят?
- Продать эту идею менеджерам. Потому что при прочих плюсах у вас увеличивается время разработки каждой фичи.
Какие минусы тут могут вас поджидать.
- Большая часть разработчиков просто не умеет тестировать, потому что они разработчики, а не тестировщики. И это нормально. Тут вы можете или научить их тестировать, что будет не самой тривиальной задачей, или просто писать тест-кейсы для них. Что де-факто ломает сам процесс.
- На старте автоматизация будет занимать больше времени, ведь не будет кодовой базы тестов, инфраструктуры и привычных подходов — задача-то новая.
- Будут нужны понятные отчёты для тестирования. Но имейте в виду: даже самый понятный отчёт не всегда можно сразу научиться правильно читать.
- Не каждую задачу вы сможете легко и быстро покрыть тестами. В ряде случаев вам придётся на тесты тратить больше времени, чем на саму реализацию фичи.
- Масштабные задачи будет сложно отдавать одновременно с тестами, это занимает довольно много времени.
- Для этих же масштабных и сложных задач надо будет всё равно закладывать время на то, чтобы просто в них вникнуть, потому что нет другого способа проверить правильность тестов, которые писали разработчики.
Что же делать?
В принципе у каждой из проблем есть решение.
- Разработчики не умеют тестировать. →
Можно консультировать их на первых этапах, чтобы помочь разобраться. - Нет кодовой базы, инфраструктуры и подходов. →
Всё решается только временем. На размеченные функции писать тексты проще. - Понятные отчёты. →
В отчёты надо включать все шаги, а название каждого теста должно сразу отражать, что именно им проверяется. - Приходится тратить много времени на ряд задач. →
Спасает здравый смысл: не всё стоит покрывать здесь и сейчас. - Сложно отдавать задачи, когда нет подходов и инструментов. →
Тоже решается постепенно, главное — время для анализа и внедрения того или иного инструмента. И это должно быть отдельной задачей. - Проблема масштабных задач. →
Их можно сразу отдавать без тестов либо частично покрытыми тестами. Но это в любом случае не отменяет погружения в контекст.
Вывод
Подход со всеми своими плюсами и минусами имеет право на жизнь. А если ещё и правильно настроить процессы, то это поможет вам и релизный цикл ускорить, и штат не раздувать (:
