Home

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

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

Добро пожаловать назад!

Внесу ясность – я не читал ни одну из этих статей. Точнее, недавно я не читал ни одной из них, а большую часть не читал никогда. Возможно, я просматривал одну или две давным-давно, но не могу вспомнить ни одной конкретной заповедей. Все то, что я еще не знал и счел разумным, я, скорее всего, давным-давно применил в своей практике. Говорю это не чтобы принизить другие статьи, а чтобы сослаться на них в том высоко вероятном случае, если некоторые из моих "заповедей" уже озвучивались до меня; я не копировал чужое, и если я повторяюсь, то надеюсь улучшить их. Я также хочу поделиться идеями, о которых вы раньше не задумывались.

Поэтому я не пишу о "ДЕСЯТИ заповедях тест-автоматизации". Вместо этого я расскажу о ЕЩЕ десяти заповедях тест-автоматизации. Поехали!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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