Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Автоматизация тестирования – это краеугольный камень непрерывного процесса поставки программного обеспечения. Автоматизация постоянно держит новые фичи под огнем тестов, которые никогда не будут вовремя завершены, если мы начнем выполнять их вручную. Однако по моему опыту код тест-автоматизации – это иногда худший код в мире разработки. Команды зачастую не придают значения его важности, объему требуемой работы и его уникальным техническим трудностям. В результате выходит не код, а громоздкая куча мусора! Его даже можно назвать "банкротом".

Что делать в этой ситуации? Полностью забить на существующее решение по автоматизации и начать заново? Может, и так, а может, и нет. Не торопитесь взорвать все, что можно, и начать сначала! Нет такого понятия, как идеальный проект, и, возможно, еще можно что-то сделать. Перезапуск автоматизации с нуля – не самое простое решение.

Уловки

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

• Тесты не добавляют ценности? Это легко исправить: просто уберите малоценные тесты. Фреймворк и тест-кейсы – это разные вещи.
• Тесты нестабильны? Найдите первопричину. Как правило, нестабильные тесты можно исправить при помощи небольшого обновления тест-кейса или какого-то аспекта фреймворка. Если нестабильна сама тестируемая фича, то исправьте фичу или подумайте, не стоит ли проверить ее вручную вместо того, чтобы автоматизировать ее тестирование.
• Изначальные авторы покинули компанию? Разберитесь в их коде до того, как создавать свой. Их код, возможно, хорош, и вы поймете это, когда разберетесь с ним.
• Команда использует плохие практики? Исправьте практики до того, как начнете вносить исправления в код, иначе новый код будет ничуть не лучше старого.

Что нужно учитывать

Вне зависимости от вышесказанного бывают ситуации, когда стоит начать сначала. Ищите сигналы этого, и действуйте с умом.

• Тест-фреймворки и пакеты устарели. Тесты, возможно, запускаются сейчас, но завтра могут и не запуститься. Найти того, кто будет над ними работать, тоже будет трудно. К примеру, nose когда-то был излюбленным Python-фреймворком, но сейчас он мертв. Выберите более современный фреймворк. Возможно, старые тесты можно частично перенести.
• Систематически нарушается независимость тест-кейсов. Каждый тест-кейс должен быть независимым. Он не должен зависеть от результатов каких-либо других тестов. Он не должен прерывать другие тесты. Лакмусовая бумажка независимости – это способность тестов успешно запускаться в любом случайном порядке. Взаимозависимые тесты трудно масштабировать и перезапускать, и они потенциально опасны. Единственный способ их исправить – это полностью все переписать.
• Юнит-тесты не отделены от функциональных тестов. Белоящичные юнит-тесты покрывают код, а черноящичные функциональные тесты покрывают живые фичи. Они занимают разные уровни тест-пирамиды и должны запускаться на разных стадиях процесса непрерывной интеграции/поставки. Решение автоматизации, не разделяющее эти типы тестов, говорит о недостатке планирования и плохой стратегии, и добиться непрерывного тестирования будет намного тяжелее.
• Фреймворку не хватает связной архитектуры, композиции и шаблонов. Хорошие решения – это конструкции, а не костыли. Конструкции масштабируются, а костыли – нет. Создание новых тестов на неустойчивой платформе приведет к неустойчивым тестам.
• Критические исправления потребуют переписывания большинства тестов. Проблемы могут быть сквозными, особенно при систематическом копировании кода. Если проблемы фреймворка так широко распространены, что тесты все равно придется переписывать – возможно, проще начать с нуля с новым решением.

Вариант ядерной бомбы

Если вы считаете, что вам необходимо начать работать над новым решением по автоматизации с нуля, убедитесь, что вы все правильно делаете. Вы же не хотите снова этим заниматься спустя пару лет! Вот парочка советов:

1. Определите свои цели. Какие проблемы вы хотите решить? Как вам поможет тестирование и автоматизация? Чего вы можете добиться в пределах своих возможностей? Хотите ли вы вносить необходимые изменения, чтобы достичь этих целей?
2. Относитесь к автоматизации, как к проекту. Тест-автоматизация – это ПО, и живет она по тем же законам и согласно тем же практикам. Она требует времени и опыта. Убедитесь, что вы выделяете достаточно времени, средств и ресурсов на ее разработку и выполнение.
3. Научитесь хорошей разработке тест-автоматизации. Это не просто "запись сценариев" – это отдельная область. Пройдите курсы Test Automation University. Читайте мой блог. Посещайте вебинары и конференции. Попросите помощи консультантов, если это необходимо.
4. Проведите черту между старым и новым решениями. Пишите все новые тесты под новым решением, продолжая запускать тесты под старым решением, если это необходимо – нет нужды хоронить это тестовое покрытие. Определитесь, стоит ли переносить старые тесты в новое решение. Это может быть хорошей возможностью для очистки старых тестов и удаления малоценных областей.

Начало создания нового тест-решения – это большой труд, но он окупится. Удачи!

Обсудить в форуме