Home

Автор: Виталий Котов

Я довольно давно и много занимаюсь автоматизацией тестирования. И не понаслышке знаю, какую боль иногда доставляют новые версии чего угодно. Обновили XCode, вышла новая Selenium, придумали новый браузер (особое спасибо Microsoft за Edge и его драйвер), зачем-то вот вам еще один язык программирования… Все это автоматизатора приводит исключительно в радость от осознания собственной значимости. Ведь только он теперь способен запустить тесты на всем этом.

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

Суть проблемы

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

Хороший пример. Если вы пишете мобильные автотесты на Java с использованием Appium, то знаете, что есть две составляющих: библиотека java_client.jar генерирует HTTP-запросы, а Appium Server эти запросы принимает. Если использовать java_client версии 4, а Appium Server выше версии примерно десятой, то поиск элементов по ID отвалится. Никакой ошибки не будет, Appium не пришлет никаких варнингов или других сигналов того, что что-то идет не так. Просто элементы перестанут находиться. И пока вы не догадаетесь поднять версию java_client, тесты обратно не заведутся. Вот же было весело во всем этом разбираться в свое время! :)

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

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

Давайте подумаем, как работать с обновлениями правильно.

Вводная

Допустим, у нас есть стабильно работающий стек технологий. В нашем случае это Java, JUnit, Java client (клиент Appium), Appium Server, библиотека Selenium, эмуляторы и симуляторы (XCode) + само приложение.

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

Выход новой версии

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

Не стоит новую версию сразу же подключать к боевому проекту. Это может поломать (и скорее всего поломает) наши тесты. А это уже заафектит тестирование регрессии и, вероятно, время выпуска очередного релиза. Придется в авральном режиме все чинить, а это никому не нужно.

Вместо этого сначала надо определиться с целесообразностью апгрейда. Для начала изучить список изменений (change list). Далее почитать отзывы в интернете: если с релизом что-то не так, очень быстро об этом появляются посты, баг-репорты или вопросы в стиле «У меня сломалось, а у кого-то еще сломалось?».

Короче, отвечаем себе на вопрос — а нам надо это обновление? И если да — насколько срочно?

Обновление

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

Добравшись до тикета, мы где-то «в сторонке» собираем тестовый проект, изменения в котором не будут аффектить боевой стек. Там мы устанавливаем новую версию и пробуем с ней запускать тесты. При необходимости вносим изменения в код или обновляем зависимые компоненты и снова запускаем тесты. И так пока не заработает. Более того, не заработает стабильно!

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

Все это время боевой стенд работает, выполняя свою основную задачу (тестирование регрессии и помощь в релизе приложения) на старом стеке. Это нормально. Процесс может занять не одну неделю или даже месяц.

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

Итого

Подходить к обновлениям надо обдуманно. Есть обязательные этапы:

=> Изучение списка обновлений

=> Планирование

=> Запуск отдельно на тестовой сборке

=> Только после стабилизации сборки — перенос на боевой стенд

Ответ на частый вопрос. Можно ли заранее знать какие версии будут работать вместе, а какие нет? Увы, нельзя. Только опытным путем собрать стек и попробовать на нем запуститься. Даже если разработчики написали, что работать должно — это не повод не протестировать заранее. :)

Такой получилось эта статья. Надеюсь, для кого-то она была полезной и сэкономит пару часов (а то и дней) на починке падающих тестов. А если вы все еще не пишите автотесты, но очень хотите научиться — приходите на наши курсы по автоматизации. Все информация о них есть у меня в профиле. :)

Спасибо за внимание!

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

В рамках курса мы поговорим о том, как с нуля написать универсальные тесты для Android и iOS, как запускать их в CI Jenkins и под конец захватим довольно объемную тему автоматизации мобильного веба.