Тренинг Баранцева про автоматизацию

Пару недель назад прошел двухдневный тренинг Алексея про автоматизацию тестирования.

Тренинг корпоративный, на 20 человек, 2 дня. Полностью посвящен теории, стратегии, управлению, планированию. Те крохи практики и примеров, которые в нем были мы беспощадно убрали, благо у нас была возможность немного подвигать программу.

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

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

Пересказывать содержимое не буду, программу тоже.
Отмечу пару моментов.
Во время тренинга Алексей просил каждого из нас письменно отвечать на разные вопросы:

• Опишите ваши проблемы с автоматизацией тестирования
• Опишите цели автоматизации
• Опишите, почему не надо заниматься автоматизацией
• Опишите, что бы вы сделали, если бы у вас была неделя

Наиболее интересны были ответы на первый и последний вопросы, так как они отлично группировались в кластера.

Сперва о проблемах. Самая главная:

Недостаток времени
Нет времени на развитие автотестов (слишком много текущих задач)
Не нравится распределение времени на ручное тестирование/автотесты
Мало времени на автотесты (написание)
На тесты постоянно не хватает времени. Чтобы освободить время, нужны тесты (много регресса). Замкнутый круг
Менеджеры не выделяют ресурсы для развития автотестов
Приходится постоянно метаться между ручным и автотестированием. И то и другое размазывается. Нужна структуризация
Не нравится, что не можем выделять задачи по автотестам в отдельные и автотесты делаются по остаточному принципу

Вторая по значимости:

Нет понимания какую область функциональности нужно покрыть автотестами
Не понятен процент покрытия автотестами
Покрытие тестами небольшое
Не весь основной критичный функционал покрыт автотестами
Разные тестеры не понимают, что проверяют автотесты
Непонятно, что проверяют тесты, доставшиеся в наследство от предыдущих тестеров
Тестами не покрыт весь функционал

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

А покрытие ручными тестами у вас есть? Как вы его измеряете, считаете, узнаете? 

 Согласен, вопрос трассировки кейсов до кода или до требований, а также вопрос измерения покрытия - ортогонален автоматизации. Это скорее про аналитику и дизайн тестов.

Теперь о том, чем мы бы занялись, если бы у нас была неделя.

От себя замечу, что неделя есть практически всегда и у всех. А Алексей добавил еще кучу способов легитимно ее найти.

Спецпроекты на неделю тоже отлично кластеризуются. Стабильность - это очень важно.

До конца разобраться со стабильностью автотестов
Нестабильность тестов, нужно больше негуевых операций
Тесты ломаются из-за изменений в контенте - надо править либо их, либо контент
Решить проблему нестабильности тестов из-за драйвера
Поднять устаревшие тесты (из-за изменения UI)
Много анимаций в интерфейсе => нестабильные тесты. Сложное обеспечение предусловий тестов.

Мы знали сами и на тренинге это неоднократно повторялось: тесты надо писать через саме надежные интерфейсы - программные, а не гуевые. Ну и обеспечение изоляции.

Второй кластер задач на неделю:
 Вычислить дублирующие проверки
Проанализировать, что есть пачками, вынести подготовку данных, использовать не перетирания, а уже существующие данные, переводить на не UI
Исследовать применение фикстур для тестовых классов
Разделить длинные сценарии на более короткие
Разбить большие сценарии на компактные, упростить сценарии. Разбить длинные сценарии на короткие (1 assert, но не до абсурда), потом объединить в группы
Тщательная проработка сценариев, выкинуть все лишнее
Функ.тесты, которые пишут разработчики, слишком длинные. Приходится разбивать
Выкинуть лишние тесты
Вынести общие части из групп тестов
У старых тестов не понятные имена и структура
много тестов на проверку логики через пользов. интерфейс (нужно перевести эти проверки на более низкий уровень)
Тех долг: оптимизация тестовых сценариев
Тех долг: увеличение покрытия существ.тестов

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

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

Картинка просто понравилась. Люблю сарказм.