Skip to content

Latest commit

 

History

History
119 lines (84 loc) · 31.4 KB

luchshie-praktiki-avtomatizacii.md

File metadata and controls

119 lines (84 loc) · 31.4 KB
Raw

Лучшие практики автоматизации

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

7 характеристик отлично написанных тестов

  • Тест полностью автоматизирован (очевидно): Иногда попадаются такие тесты, которые автоматизированы не полностью. Самые распространенные причины: либо это очень сложно, либо просто невозможно;
  • Тест повторяем: тест не ломается, если приложение не поменялось: Это относится к основам генерации уникальных данных. Например, мы тестируем регистрацию. Очевидно, что если не генерировать уникальный емейл, то на продакшене такой тест, скорее всего, не будет работать;
  • Тест заканчивается валидацией: За исключением случаев, где нужно выполнить действия по зачистке данных и подобных действий, завершение валидацией является лучшей практикой. Это помогает убедиться, что последнее действие прошло успешно;
  • Тест достаточно стабилен, чтобы его использовать в CI/CD: Если тест регулярно ломается, то он недостаточно стабилен, чтобы использовать его в CI/CD. Так как практически любая компания пытается добиться CI или даже CD, то часто такой тест не просто бесполезен, но даже вреден, так как отнимает большое количество времени и все равно не может использоваться в CI автоматически;
  • Тест очень легко читать: Мы обычно не пишем тесты в одиночку. Часто это команда людей и нашим коллегам тоже приходится поддерживать наши тесты. Крайне важно, чтобы любой член команды мог разобраться в структуре теста, не тратя на это излишнее количество времени. Даже если мы пишем тесты в одиночку, иногда бывает очень тяжело понять, что тест делает и как, если он не написан специально для облегчения понимания;
  • Тест требует минимальной поддержки: Пункт очевидный, но не всегда соблюдаемый. Чем меньше мы тратим времени на поддержку, тем больше у нас времени на то, чтобы сделать что-то полезное, как, например, написать больше тестов;
  • Тест работает параллельно с другими тестами и не ломается: В какой-то момент, особенно для end-to-end тестов, мы сталкиваемся с тем, что прогон тестов занимает слишком много времени, это снижает скорость разработки и приводит к таким эффектам, как неоттестированный патч. На этом этапе мы обычно задумываемся о параллелизации, чтобы ускорить исполнение тестов. Если тесты были написаны так, что они могут быть запущены параллельно в любой последовательности и не пересекаться друг с другом, то это делает задачу параллельного исполнения просто задачей настройки инфраструктуры, а не задачей переписывания тестов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как можно и нельзя автоматизировать

Нельзя:

  • Автоматизировать все ручные тесты: ручные тесты прекрасны - они находят проблемы, о которых вы даже не помышляли. Но ручной подход к тестированию не всегда можно напрямую перенести на автоматизированные проверки. Возможно, стоит создать новые сценарии специально для автоматизации.
  • Делать автотесты задачей одного-единственного человека: когда вы только начинаете, найм консультанта по автоматизации - хорошая мысль, однако убедитесь, что соответствующие знания доступны всем участникам проекта. В один прекрасный день консультант или ключевой исполнитель покинет вас, и разбираться с тест-набором придется всем остальным.
  • Автоматизировать все на свете: сценарий автоматизируется не просто так - на это есть причины, его автоматизация каким-то образом ценна для проекта. Начните с рутинных задач, которые все равно выполняются ежедневно - и вы сразу увидите первую, мгновенную выгоду от усилий по автоматизации.
  • Автоматизировать, просто чтобы автоматизировать: подумайте, что вам нужно, и что нужно прямо сейчас. Если вы настроены на 80-100% автоматизацию во всех проектах просто потому, что "это круто и так хочет генеральный директор, или "это хорошо звучит на собраниях совета директоров", то вы попусту тратите время и деньги.
  • Покупать лидирующий по рынку, наилучший инструмент автоматизации: найдите инструмент, который подходит под ваши задачи, и убедитесь, что он действительно делает то, что обещает. Не поддавайтесь на уговоры продавцов купить дорогостоящую программу, которая очень крута прямо сейчас в этом конкретном проекте или на этой конкретной платформе. И не заставляйте другие проекты использовать инструмент, если он им не нужен.
  • Думать в терминах "прошел" и "упал": у вас будут упавшие кейсы. Это не значит, что там есть ошибка. Не воспринимайте упавший тест как сигнал о баге - вам нужно разобраться, ПОЧЕМУ тест упал. Также подумайте, действительно ли категории "прошел/упал" подходят для отчетности об автотестах? Возможно, стоит подумать о другой классификации, которая лучше опишет происходящее?
  • Запускать все подряд каждый божий раз: подумайте о цели прогона ваших тестов. Если вам не нужно тестировать отдельную область - не делайте этого, тестируйте только ту функциональность, которая в этом нуждается. Прочее тестирование - это лишняя трата времени и сил, которая замусорит ваш отчет ненужными данными. Конечно, некоторые проверки могут гоняться постоянно, но убедитесь в том, что это оправданные меры.
  • Забывать тестировать собственные тесты: привыкайте к идее тестировать свои тесты. Автоматизированный тест-сценарий не должен выпускаться в мир, пока вы не увидели, как он несколько раз упал. Запускайте тест в обстоятельствах, когда он безусловно упадет, чтобы учесть это, когда он будет выпущен в релиз.
  • Недооценивать усилия по поддержке автоматизированного набора тестов: автоматизированный тест-сьют - не та штука, которую сделал и забыл, а она бегает себе там. Ваша система постоянно меняется, и тест-набор нужно обновлять и пополнять беспрестанно. Не сваливайте эту ответственность на единственного тех-тестировщика в вашей компании.

Нужно:

  • Дробить тесты на независимые сценарии: куда легче определить, где гнездятся проблемы и ошибки, если ваш тест-набор состоит из кратких, конкретных тест-сценариев. Не пытайтесь впихнуть все в один сценарий. Очень, ОЧЕНЬ трудно разобраться, что же пошло не так, если вам надо докопаться до всего на свете, проверяющегося в вашем тесте. Пусть тесты будут краткими и простыми.
  • Сделать автоматизацию задачей всей команды проекта: почему бы не дать возможность всем, а не только тестировщикам, влиять на набор автотестов? Разработчики, менеджеры проекта, продакт-оунеры - всем им есть что сказать на предмет автоматизированного тестирования, и они могут принести ему пользу.
  • Донести информацию о результатах автоматизированного тестирования до всех - и подумать, кто получает эти результаты: предоставьте разную информацию разным людям в проекте. Разработчику нужна специфическая информация о прогоне автотестов, и она безразлична менеджеру проекта. Опросите всех заинтересованных лиц, выясните, какая информация им требуется.
  • Начинать с простых вещей и пополнять тест-сьюты по ходу дела: начните с того, что вам необходимо, и следуйте по воркфлоу проекта. Проекты постоянно меняются - не надо тратить время, силы и деньги на то, что не будет использовано или изменится в последний момент. Создавайте набор тестов по кусочкам, шаг за шагом.
  • Заставить ваш фреймворк работать на износ: вы приобрели дорогую программу, настроили ее и потратили время на создание и обновление наборов тестов. Пользуйтесь этим! Создайте набор, который может прогоняться часто и при этом ценен для проекта! Набор автотестов, который не запускается - это пустая трата денег.
  • Учитывать проектные и организационные изменения: найдите программу, которая способна расти вместе с вашими проектами и вашей организацией, и выясните, что вы можете - и не можете - с ней делать. Если она вам не подходит, отбросьте ее. Нет смысла тратить силы и время на неподходящие вам ресурсы.
  • Разгрузить ручных тестировщиков: думайте о наборе автотестов как о помощи мануальным тестировщикам. Освободите их от нудных повторяющихся задач, пусть они делают то, в чем они звезды - тестируют, а не тупо следуют сценариям.
  • Сделать запуск тестов простым и быстрым: настройка и старт набора автотестов должна быть простой задачей и давать мгновенную обратную связь. Если ваш тест-набор замедлен или очень сложен, люди просто не будут заморачиваться с запуском.
  • Постоянно обновлять тест-набор: если меняется ваш код - меняются автотесты, и это ваше золотое правило. Оно верно для ВСЕХ изменений базы кода. Правки багов, внедрение фич - все это ведет к изменениям тест-набора.

О паттернах проектирования/архитектуре есть ссылки в доп. материалах ниже. О создании фреймворка в теме про виды и инструменты.

Источники:

Доп. материал: