Тесты должна писать разработка (?)

Привет! Есть старый холивар на тему, кто же должен писать тесты: разработчики или тестировщики. Вроде как если в команде есть тестировщики, то логично, что тесты пишут они, правда? С другой стороны, ребята из разработки (помимо самой разработки) точно знают, как работает их код и как будет вести себя в тех или иных ситуациях. Как минимум предполагают.

Дисклеймер: меня зовут Эрик Бурыгин, я давно работаю тестировщиком, веду студентов на курсе «Инженер по тестированию», поэтому может показаться, что тестировщик просто хочет перекинуть кусок работы на разработчиков. На самом деле у описываемого подхода есть как плюсы, так и минусы, поэтому статья носит в том числе и дискуссионный характер. Буду рад увидеть в комментах мнения как разработчиков, так и тестировщиков.

Если тесты пишет разработка, можно решить сразу несколько проблем, например:

• Ощутимо ускорить релизный цикл.
• Снять нагрузку с тестирования.

В большинстве команд процесс выглядит примерно так:

1. Разработчик создаёт новые фичи и допиливает существующие.
2. Тестировщик всё это тестирует и пишет различные тест-кейсы.
3. Автоматизатор, оправдывая название должности, автоматизирует всё по написанным тест-кейсам из п.2.

Вроде бы всё выглядит просто.

Но в этой парадигме есть слабые места.

Допустим, разработчик доделал свою фичу и благополучно отдал её в тестирование. Но фича получилась не medium rare, а откровенно сырая. Это приведёт к переоткрытию задачи и дополнительным фиксам, причём итераций может быть от одной до N, в зависимости от размера этой фичи, её сложности, влияния на смежные процессы, добросовестности самого разработчика. А ещё от того, как у вас в принципе устроены процессы внутри разработки, насколько тщательно смотрятся пул-реквесты, запускается ли приложение перед отправкой на тестирование.

В общем, переменных хватает.

После того как задача будет протестирована и готова к релизу, тестированию нужно написать на весь функционал тест-кейсы. Затем сделать регресс/смоук и наконец зарелизить.

Автоматизатор же после получения написанных тест-кейсов покрывает тестами функционал. Здесь есть довольно большая вероятность, что задача попадёт в существующую очередь, поэтому тесты будут написаны с задержкой.

— Просто нужно больше разработчиков

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

А это по принципу домино увеличит нагрузку уже на автоматизаторов, которым придётся обрабатывать всё большее и большее количество тест-кейсов, падающих на них от тестирования. Будет зеркальная ситуация: или увеличится время покрытия тестами, или штат автоматизаторов.

На восемь разработчиков обычно приходится два тестировщика и один автоматизатор. Автоматизация при этом не участвует в релизном цикле напрямую — скорее находится поблизости. И возникает вопрос: как сделать описанные процессы более эффективными, да ещё и не потерять в качестве?

Давайте попробуем сдвинуть этап автоматизации с третьего места на первое, на этап разработки.

Что получится

Получится сразу неплохой набор плюсов, смотрите:

• разработчики пишут тесты одновременно с написанием самой фичи, что существенно улучшает её качество;
• падает нагрузка на тестирование: тестировщикам теперь надо посмотреть результаты тестов и оценить, в достаточной ли степени задача покрыта тестами;
• ручного регресса в схеме больше нет за ненадобностью.

А что тестировщики?

Тестировщик и в обновлённой парадигме остаётся экспертом в тестировании — именно он ревьюит как качество, так и полноту покрытия автотестами той или иной фичи, а также занимается анализом сложных и необычных проблем. Но теперь, благодаря снижению нагрузки, у тестировщика освобождается часть времени, он может заниматься процессами.

При этом надо понимать, что ручное тестирование всё равно никуда не денется — у вас всегда будет что-то, что по какой-то причине автоматизировать либо невозможно, либо не имеет смысла.

Так вот, к новой парадигме. Круто же? Да хоть прямо сейчас внедрять. Если получится сделать две вещи.

1. Продать эту идею разработке. Потому что далеко не каждый разработчик сразу захочет писать тесты, ведь это может быть скучно, или он просто не хочет: у вас, вообще-то, тестировщики вон там для чего сидят?
2. Продать эту идею менеджерам. Потому что при прочих плюсах у вас увеличивается время разработки каждой фичи.

Какие минусы тут могут вас поджидать.

1. Большая часть разработчиков просто не умеет тестировать, потому что они разработчики, а не тестировщики. И это нормально. Тут вы можете или научить их тестировать, что будет не самой тривиальной задачей, или просто писать тест-кейсы для них. Что де-факто ломает сам процесс.
2. На старте автоматизация будет занимать больше времени, ведь не будет кодовой базы тестов, инфраструктуры и привычных подходов — задача-то новая.
3. Будут нужны понятные отчёты для тестирования. Но имейте в виду: даже самый понятный отчёт не всегда можно сразу научиться правильно читать.
4. Не каждую задачу вы сможете легко и быстро покрыть тестами. В ряде случаев вам придётся на тесты тратить больше времени, чем на саму реализацию фичи.
5. Масштабные задачи будет сложно отдавать одновременно с тестами, это занимает довольно много времени.
6. Для этих же масштабных и сложных задач надо будет всё равно закладывать время на то, чтобы просто в них вникнуть, потому что нет другого способа проверить правильность тестов, которые писали разработчики.

Что же делать?

В принципе у каждой из проблем есть решение.

1. Разработчики не умеют тестировать. →
   Можно консультировать их на первых этапах, чтобы помочь разобраться.
2. Нет кодовой базы, инфраструктуры и подходов. →
   Всё решается только временем. На размеченные функции писать тексты проще.
3. Понятные отчёты. →
   В отчёты надо включать все шаги, а название каждого теста должно сразу отражать, что именно им проверяется.
4. Приходится тратить много времени на ряд задач. →
   Спасает здравый смысл: не всё стоит покрывать здесь и сейчас.
5. Сложно отдавать задачи, когда нет подходов и инструментов. →
   Тоже решается постепенно, главное — время для анализа и внедрения того или иного инструмента. И это должно быть отдельной задачей.
6. Проблема масштабных задач. →
   Их можно сразу отдавать без тестов либо частично покрытыми тестами. Но это в любом случае не отменяет погружения в контекст.

Вывод

Подход со всеми своими плюсами и минусами имеет право на жизнь. А если ещё и правильно настроить процессы, то это поможет вам и релизный цикл ускорить, и штат не раздувать (: