Автоматизация: как работать с обновлениями
Привет, Хабр!
Я довольно давно и много занимаюсь автоматизацией тестирования. И не понаслышке знаю, какую боль иногда доставляют новые версии чего угодно. Обновили 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). Далее почитать отзывы в интернете: если с релизом что-то не так, очень быстро об этом появляются посты, баг-репорты или вопросы в стиле «У меня сломалось, а у кого-то еще сломалось?».
Короче, отвечаем себе на вопрос —, а нам надо это обновление? И если да — насколько срочно?
Обновление
Когда понимаем, что апгрейд нужен, создаем тикет на обновление, добавляем его в наше планирование. Это вполне себе такая же задача, как и другие: написание нового теста, внесение изменений в инфраструктуру и так далее. На текущий момент задача обновления может быть менее приоритетной, чем другие в бэклоге — это тоже нормально.
Добравшись до тикета, мы где-то «в сторонке» собираем тестовый проект, изменения в котором не будут аффектить боевой стек. Там мы устанавливаем новую версию и пробуем с ней запускать тесты. При необходимости вносим изменения в код или обновляем зависимые компоненты и снова запускаем тесты. И так пока не заработает. Более того, не заработает стабильно!
Важно: в конечном итоге обязательно надо прогнать тесты еще раз после добавления всех новых версий и внесения изменений в код.
Все это время боевой стенд работает, выполняя свою основную задачу (тестирование регрессии и помощь в релизе приложения) на старом стеке. Это нормально. Процесс может занять не одну неделю или даже месяц.
Когда мы уверены в новом стеке, его можно переносить на боевой стенд. Лучше делать это как можно дальше от релиза по времени, чтобы все же было время откатиться.
Итого
Подходить к обновлениям надо обдуманно. Есть обязательные этапы:
=> Изучение списка обновлений
=> Планирование
=> Запуск отдельно на тестовой сборке
=> Только после стабилизации сборки — перенос на боевой стенд
Ответ на частый вопрос. Можно ли заранее знать какие версии будут работать вместе, а какие нет? Увы, нельзя. Только опытным путем собрать стек и попробовать на нем запуститься. Даже если разработчики написали, что работать должно — это не повод не протестировать заранее. :)
Такой получилось эта статья. Надеюсь, для кого-то она была полезной и сэкономит пару часов (а то и дней) на починке падающих тестов. А если вы все еще не пишите автотесты, но очень хотите научиться — приходите на наши курсы по автоматизации. Все информация о них есть у меня в профиле. :)
Спасибо за внимание!
