Home

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я опубликовал пост в LinkedIn и Twitter:

“Упоминал ли я, что разработка автоматизации - это разработка ПО? Нет? Считайте, что теперь упомянул”.

Как это часто бывает, ответил Майкл Болтон:

“Что такое “автоматизация”-то? Это серьезный вопрос, и мне кажется, что его задают недостаточно часто. Когда люди говорят об автоматизации, что именно автоматизируется?”

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

В моем широком контексте автоматизация - это рациональное применение технологии для упрощения работы людей. Люди, которым я обычно помогаю - это тестировщики и те, кто выполняет связанные с тестированием задачи. Центральная идея этого определения: “Задействуем машины, чтобы помочь людям быть эффективнее и продуктивнее в их деятельности”.

Какие формы может принимать эта “помощь”? Например, такие:

-      Скрипты для создания или ввода данных

-      Скрипты для выполнения определенных действий после каждого билда

-      Скрипты для выполнения определенных действий в определенное время или интервал времени

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

-      Скрипты для выполнения сложных расчетов или сравнений, для чего отлично подходят машины (а люди - плохо).

Некоторые скрипты можно классифицировать как то, что обычно называют “тест-автоматизацией” - то есть те, которые произошли от тест-кейсов и обычно имеют результат “пройдено или упало”. Другие я бы назвал автоматизированной помощью - это скрипты, помогающие тестировщику нетрадиционным образом. Зачастую эти скрипты не выдают результат “пройдено или упало”; они больше связаны с “запуском двигателя” приложения путем выполнения рутинных задач, для которых хорошо подходят компьютеры: ввод данных, математика, или рутинное нажатие на кнопки.

Вместо того, чтобы разделять традиционную автоматизацию и автоматизированную помощь, не стоит ли назвать это все автоматизированной помощью? Или автоматизацией в тестировании? Или просто тестированием? Конечно, можно. Однако мы с Майклом уже как-то раз обсуждали автоматизированное тестирование больших объемов (HiVAT). Тогда он говорил, что на самом деле оно должно называться автоматизированной проверкой больших объемов. Я ответил, что если называть это менее известным и популярным среди поисковиков именем, то документацию по HiVAT будет труднее найти.

Это похоже на мое взаимодействие с людьми в качестве консультанта. Если называть инструменты, технологии и концепции незнакомыми людям именами, то это может затормозить прогресс. Называя их известными именами, мы повышаем комфорт в ходе процесса перемен, который сам по себе в любом случае некомфортен. Затем я добавляю новую терминологию для “новых” подходов и техник, чтобы их различать.

Возвращаясь к затронутой в твите теме разработки автоматизации - почему мы должны считать ее разработкой ПО? Потому что это практически всегда именно она и есть. Когда мы пишем тест-сценарии, используя традиционные языки программирования вроде C#, Python и т. п., мы создаем ПО, помогающее нам выполнять свою работу. Мы вовлекаемся в ряд задач, характерных для разработки ПО:

-      Планирование

-      Дизайн

-      Ревью

-      Тестирование

-      Дебаг

-      Хранение.

Даже используя инструменты записи и воспроизведения, записи и генерации, или перетаскивания, мы располагаем шаги в определенном порядке для последующего использования; это по сути программирование. Эти инструменты дают артефакт, который, возможно, стоит хранить и версионировать, совсем как “созданное вручную” ПО. Они дают результаты, которые, возможно, надо хранить, просматривать на правильность соответствия ожиданиям и приемлемость (поддерживаемость, читабельность, хрупкость), совсем как “созданное вручную” ПО. Не отбрасывайте этот подход к автоматизации как “не-разработку” просто потому, что не видите синтаксиса под капотом.

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