Читайте нас в телеграм:

Верстальщик от бога

Самый большой канал по верстке в телеграм

Программист от бога

Божественный юмор о программистах

Тестировщик от бога

Божественный канал о тестировании

АйТи собес

Логический задачи с айтишных собеседований

Десять заповедей автоматизации

Software-testing.ru опубликовал перевод статьи Пола Гриззаффи с рекомендациями для автоматизаторов.

I – Неавтоматизируйтолько «потест-кейсам»

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

В этом подходе может быть смысл, но другие подходы принесут не меньше, а то и больше выгоды. Расширяя определение автоматизации за рамки «тест-кейс – инструмент – тест-скрипт» до «продуманного применения технологии с целью помочь людям выполнять свою работу», мы можем использовать компьютерные мощности для задач, для которых они предназначены, а люди – тестировщики – пусть делают все остальное. К счастью, в большинстве задач, где хороши люди, компьютеры выступают плохо – и наоборот.

II – Обращайся с разработкой автоматизации, как с разработкой ПО

Разработка автоматизации – это и есть разработка ПО. Даже если мы используем интерфейс перетаскивания или записи и воспроизведения для создания автоматизации, то где-то под капотом или за занавесом над нашими действиями работает код. Мы должны начать обращаться с автоматизацией как с разработкой ПО, иначе мы окажемся с чем-то неподдерживаемым на руках, и проект умрет, едва родившись.

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

  • Дизайн – мы должны решить, что внедрять и как это делать, чтобы это было поддерживаемым и пригодным к эксплуатации.
  • Внедрение – надо написать код.
  • Хранение – код и его артефакты должны где-то храниться.
  • Тестирование – тестировать тесты? Естественно! Мы должны быть достаточно уверены, что автоматизация ведет себя так, как нам хочется. Если мы не доверяем автотестам, в них нет смысла.
  • Баги – в любом ПО есть баги; автоматизация, как ПО, не исключение. Тестирование поможет нам, но не отловит все баги на свете. Выделите время на исправление багов.
  • Логи – это артерия автоматизации. Без них мы не поймем, что автоматизация делает, и не сможем ее починить, когда она сломается. К тому же мы не сможем сказать, в автоматизации ли кроется проблема, или же в тестируемом ПО.

III – Следуй стандартам и идиомам программирования

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

IV – Не забывай про поддержку и обслуживание

ПО не идеально и никогда не бывает полностью готово; с автоматизацией то же самое. В ней будут баги. С изменением тестируемого приложения нужно будет соответственно менять автоматизацию. Мы не можем это предотвратить, но можем разработать наше ПО так, чтобы снизить затраты на его поддержку и обслуживание; и на них тоже надо выделить время. Эта статья и этот пост в блоге рассказывают о факторах, которые надо учитывать, планируя будущую поддержку.

V – Не делай скрипты зависимыми друг от друга

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

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

VI – Внедряй грамотное логирование и отчеты

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

VII – Влияй на тестируемость и автоматизируемость

Тестируемость, та степень, до которой приложение или фича могут быть протестированы, и автоматизируемость, степень, до которой тест-деятельность может выполняться автоматически – это не то, что могут создавать тестировщики, QA и QE, но, конечно, есть вещи, на которые мы можем повлиять. Осуществление этого влияния – наша обязательная задача. Разработчики не всегда знают, что нам нужно для тестирования и для создания автотестов. Мыдолжныдонестиэтодоних. Статьи здесь и здесь рассказывают о некоторых аспектах тестируемости и автоматизируемости.

VII – Не попадайся в ловушку невозвратных затрат

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

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

Возможно, мы эмоционально привязаны к нашему программному «ребенку»; мы потратили на него столько времени и денег, что не в силах выбросить его и начать заново. Возможно, мы боимся; руководство, скорее всего, не придет в восторг, захоти мы бросить все и снова сделать «то же самое». Мы должны рассматривать такие ситуации с точки зрения бизнеса, а не предаваться эмоциям.

IX – Опасайся хитроумных приспособлений

Машины Руба Голдберга – это сложные машины, выполняющие сравнительно простые задачи, вроде «Автономного платочка«. В мире автоматизации создание таких машин – очень веселое дело, и они могут делать крутые штуки вроде увязывания вместе разных инструментов для выполнения тест-задач. Минус в том, что это сложно понимать и поддерживать; надо опасаться создания того, что сложнее поддерживать, нежели выполнять эти задачи вручную. Эта статья расскажет больше об автоматизированных машинах Руба Голдберга; этот пост размышляет о состоянии «автоматизированности».

X – Не делай тестовые данные зависимыми от временных данных

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

В этом случае надо не жестко кодировать даты июля, а динамически генерировать данные на основании текущего месяца.

Читайте также

Обсуждение

ОСТАВЬТЕ ОТВЕТ

Пожалуйста, введите ваш комментарий!
пожалуйста, введите ваше имя здесь

читайте нас в телеграм

Верстальщик от бога

Самый большой канал по верстке в телеграм

Программист от бога

Божественный юмор о программистах

Тестировщик от бога

Божественный канал о тестировании

АйТи собес

Логические задачи на собеседованиях в IT

Фронтендер от бога

Божественный канал о тестировании

Mobile Dev Lib

Популярное

10 опенсорсных инструментов в помощь разработчику

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

Как войти в Java в 2021 году

Советы преподавателя как войти в Java в 2021 году. Что почитать по Java, как найти галеру, книжки по Java, competitive programming

Выбираем между React и Angular

Разбираемся, что лучше использовать в современной фронтенд-разработке.