Ошибки автоматизации | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
Python Developer. Basic Специализация Python Developer
-25%
iOS Developer. Professional Архитектура и шаблоны проектирования Scala-разработчик Python Developer. Professional JavaScript Developer. Professional Программист С Kotlin Developer. Basic Android Developer. Basic Node.js Developer Специализация Java-разработчик
-25%
PHP Developer. Basic C# Developer. Professional Symfony Framework Алгоритмы и структуры данных MS SQL Server Developer NoSQL Golang Developer. Professional Framework Laravel Разработчик программных роботов (RPA) на базе UiPath и PIX Kotlin Backend Developer C# ASP.NET Core разработчик Специализация Java и Базы данных Подготовка к сертификации Oracle Java Programmer (OCAJP) Unity Game Developer. Professional Специализация iOS Специализация C# Unreal Engine Technical Game Design Rust Developer
Специализации Курсы в разработке Подготовительные курсы Подписка
+7 499 938-92-02

Ошибки автоматизации

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

Facepalm_1-1801-7c50da.jpg

Худшее, что можно сделать уже на самом старте (к сожалению, такое до сих пор нередко встречается), -- это запихнуть все задачи в один-единственный тикет с расплывчатым названием в стиле "Создание автотестов". И сконцентрировать в этом тикете все проблемы и сложности. Как только вы это сделаете, можете быть уверены -- ваше личное видение автоматизации никогда не воплотится в реальность.

Горькая правда заключается в том, что до сих пор многие компании относятся к автоматизации, как к какой-то фоновой задаче, работать над которой имеет смысл лишь во время простоя.

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

Таким образом, отдельная доска для требуемых тикетов по автоматизации – это не излишество, а жизненная необходимость, ведь работа должна быть: - грамотно детализированной; - правильно оцениваемой; - регулярно отслеживаемой.

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

2-1801-a5c530.png

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

Пять советов по успешному запуску тестовой автоматизации:

  1. Не имеет значения, какие инструменты вы используется – JIRA, Azure или Favro – вам надо создать отдельный проект/пространство для тикетов по автоматизации тестирования. Рекомендуется подойти максимально серьезно к этому вопросу и провести декомпозицию, то есть, как и для любого другого проекта, создать эпики, стори, спайки, задачи. И учесть все это в спринтах и релизах, то есть поставить четкие цели и стремиться к их достижению, а не бесцельно/бесконечно копаться в тикетах.
  2. В приоритете долгосрочное планирование. Стремление к быстрому выигрышу -- это ошибка. Да, вы можете запуститься очень быстро, но последующие серьезные проблемы нивелируют ваши профиты. Мыслить надо стратегически, выбирая инструменты и технологии с учетом долгосрочных целей. Чтобы быстрее стартовать, можно где-то и пойти на компромисс, но ни в коем случае нельзя строить фундамент автотестов на основе краткосрочных целей -- это тоже ошибка.
  3. Удостоверьтесь в том, что способ запуска тестов существует не только на собственном компьютере. И не имеет значения, что это: виртуальная лаборатория, облако либо физическая машина. Запускать тесты только на своей машине -- это ошибка. И даже если это все, что сейчас у вас есть, это лучше, чем ничего, однако со временем автоматизированные тесты будут прогоняться дольше и дольше, следовательно, вам придется сидеть и ожидать, когда они завершатся.
  4. Не стоит работать в одиночку, разработчики тоже могут помочь. Практика показывает, что для действительно успешной автоматизации поддержка разработчиков очень нужна, и не столь важно, идет ли речь о создании тестов, работе с фреймворком либо даже банальном прогоне тестов. Сотрудничать с разработчиками можно и нужно -- благодаря этому вы будете уверены, что система непрерывной интеграции будет настроена правильно и эффективно.
  5. Настойчивость и еще раз настойчивость. В процессе работы вы гарантированно столкнетесь с препятствиями. Потребуется лицензия, настройка окружения, какие-нибудь права доступа и пр. Иногда вы будете тонуть в вопросах бюрократии и канцелярщины, связанных с заказом и оплатой лицензии. Тут главное проявить твердость и настойчивость, иногда даже навязчивость. Всегда помните о том, что если реализация проекта начнет "тормозить", то с каждой последующей задержкой вам будет все труднее бороться за нужные ресурсы и поддержку. А значит, повышается риск, что ваши уже затраченные усилия пропадут даром.

1-1801-832764.png

Источник -- https://www.learnautomation.co.uk/2020/07/mistakes-the-automation-ticket/.

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться
🔥 Черная пятница!
Любой доступный курс OTUS можно купить со скидкой по промокоду — blacksale21