Привет, Хабр!
И не понаслышке знаю, какую боль иногда доставляют новые версии чего угодно. Я довольно давно и много занимаюсь автоматизацией тестирования. Ведь только он теперь способен запустить тесты на всем этом. Обновили XCode, вышла новая Selenium, придумали новый браузер (особое спасибо Microsoft за Edge и его драйвер), зачем-то вот вам еще один язык программирования… Все это автоматизатора приводит исключительно в радость от осознания собственной значимости.
На нашем курсе по автоматизации ученики часто спрашивают про то, как работать с новыми версиями тех или иных составляющих стека. Менее опытные ребята, кто только постигают все азы и таинства работы с тестами, почему-то радость не испытывают. Кому интересно — добро пожаловать под кат. Об этом сегодня я и решил рассказать.
Суть проблемы
Основная проблема в том, что заранее невозможно предсказать поведение системы после изменения версии любой составляющей стека. Самое смешное, вам никто четко не скажет, что такая-то версия одной софтины не будет работать с такой-то версией другой. Все эти сокровенные знания берегут как зеницу ока.
Если вы пишите мобильные автотесты на Java с использованием Appium, то знаете, что есть две составляющих: библиотека java_client.jar генерирует HTTP-запросы, а Appium Server эти запросы принимает. Хороший пример. Никакой ошибки не будет, Appium не пришлет никаких варнингов или других сигналов того, что что-то идет не так. Если использовать java_client версии 4, а Appium Server выше версии примерно десятой, то поиск элементов по ID отвалится. И пока вы не догадаетесь поднять версию java_client, тесты обратно не заведутся. Просто элементы перестанут находиться. 🙂 Вот же было весело во всем этом разбираться в свое время!
Плохо, если в этом случае мы начинаем хаотично обновлять оставшиеся составляющие стека. Частая ситуация: новая версия работает с багами или просто не дружит с текущими версиями других программ. Это наверняка повлечет за собой еще больше обновлений и нестабильности.
В неопытных руках все это может привести к чему угодно вплоть до полной поломки автотестов.
Давайте подумаем, как работать с обновлениями правильно.
Вводная
Допустим, у нас есть стабильно работающий стек технологий. В нашем случае это Java, JUnit, Java client (клиент Appium), Appium Server, библиотека Selenium, эмуляторы и симуляторы (XCode) + само приложение.
Тут важно понимать, что именно это их основная задача. На этом стеке уже написано какое-то количество тестов, которые проверяют регрессию приложения перед его релизом. Релиз сломанного приложения может повлиять на его репутацию и даже повлечь за собой финансовые убытки.
Выход новой версии
Далее у одного из компонентов стека выходит обновление. Это будет происходить регулярно, так как наш стек включает в себя много программ и библиотек.
Это может поломать (и скорее всего поломает) наши тесты. Не стоит новую версию сразу же подключать к боевому проекту. Придется в авральном режиме все чинить, а это никому не нужно. А это уже заафектит тестирование регрессии и, вероятно, время выпуска очередного релиза.
Для начала изучить список изменений (change list). Вместо этого сначала надо определиться с целесообразностью апгрейда. Далее почитать отзывы в интернете: если с релизом что-то не так, очень быстро об этом появляются посты, баг-репорты или вопросы в стиле «У меня сломалось, а у кого-то еще сломалось?».
И если да — насколько срочно? Короче, отвечаем себе на вопрос — а нам надо это обновление?
Обновление
Когда понимаем, что апгрейд нужен, создаем тикет на обновление, добавляем его в наше планирование. Это вполне себе такая же задача, как и другие: написание нового теста, внесение изменений в инфраструктуру и так далее. На текущий момент задача обновления может быть менее приоритетной, чем другие в бэклоге — это тоже нормально.
Там мы устанавливаем новую версию и пробуем с ней запускать тесты. Добравшись до тикета, мы где-то «в сторонке» собираем тестовый проект, изменения в котором не будут аффектить боевой стек. И так пока не заработает. При необходимости вносим изменения в код или обновляем зависимые компоненты и снова запускаем тесты. Более того, не заработает стабильно!
Важно: в конечном итоге обязательно надо прогнать тесты еще раз после добавления всех новых версий и внесения изменений в код.
Это нормально. Все это время боевой стенд работает, выполняя свою основную задачу (тестирование регрессии и помощь в релизе приложения) на старом стеке. Процесс может занять не одну неделю или даже месяц.
Лучше делать это как можно дальше от релиза по времени, чтобы все же было время откатиться. Когда мы уверены в новом стеке, его можно переносить на боевой стенд.
Итого
Подходить к обновлениям надо обдуманно. Есть обязательные этапы:
=> Изучение списка обновлений
=> Планирование
=> Запуск отдельно на тестовой сборке
=> Только после стабилизации сборки — перенос на боевой стенд
Можно ли заранее знать какие версии будут работать вместе, а какие нет? Ответ на частый вопрос. Только опытным путем собрать стек и попробовать на нем запуститься. Увы, нельзя. 🙂 Даже если разработчики написали, что работать должно — это не повод не протестировать заранее.
Надеюсь, для кого-то она была полезной и сэкономит пару часов (а то и дней) на починке падающих тестов. Такой получилось эта статья. Все информация о них есть у меня в профиле. А если вы все еще не пишите автотесты, но очень хотите научиться — приходите на наши курсы по автоматизации. 🙂
Спасибо за внимание!
