Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru, и мы продолжаем серию ответов на самые популярные вопросы про автоматизацию тестирования. Ранее мы уже ответили на вопросы ручного тестировщика и менеджера. Пришло время ответить на пять самых страшных вопросов от технического директора — как не проиграть при выборе фреймворка для автоматизации, про сложность найма и трудозатраты на поддержку автотестов.
Видеоверсию моих ответов можно посмотреть и послушать тут.
Вопрос 1. Как выбрать фреймворк для автотестов?
Начнем с истории о том, как мы выбирали фреймворк для автотестов android.
Однажды одна команда разработчиков и тестировщиков hh.ru решила, что было бы неплохо автоматизировать регресс. И начался большой подробный ресерч.
Мы изучали, что уже есть на рынке:
с какими проблемами сталкиваются пользователи этих фреймворков
как быстро и качественно эти проблемы решаются
как часто приходится вбивать костыли, чтобы автотесты работали стабильно
актуальность в сообществе
В итоге получили таблицу с плюсами и минусами каждого фреймворка, из которых мы начали выбирать.
Мы определили, что для нас наиболее важно — например, чтобы писать автотесты было легко, чтобы они были читаемы и понятны как тестировщикам, так и разработчикам. Таким образом мы отсеяли все неподдерживаемые, сложные, кроссплатформенные, нестабильные фреймворки и остановились на Kakao.
Kakao — это обертка над всем известным Espresso. Писать автотесты на нём уже было гораздо проще и удобнее. Как минимум, определение элемента не занимало у нас 3-5 строк кода, как на Espresso. На Kakao мы автоматизировали примерно полгода, и за это время у нас появилось четкое представление, чего нам не хватает в выбранном фреймворке. Так появился Kaspresso, в котором все наши хотелки были реализованы.
Kaspresso — еще более удобный фреймворк. Он помогает не только писать автотесты легко, но и делать их стабильными и читаемыми. Под капотом у Kaspresso много полезного функционала, благодаря которому даже самые сложные проверки мобильных приложений пишутся достаточно легко.
Помимо всего написанного о преимуществах и прелестях Kaspresso, мы добавили в него степы (steps) — человекочитаемое описание того, что делаем в тесте или в методе. Из этих степов формируется пошаговый отчет — видно, какие шаги тест прошел и на каком шаге упал. Также мы сделали dsl для создания тестовых данных. Подробнее об этом можно почитать в этой статье.
С iOS история гораздо короче и проще. Тут всё из коробки — XCUITest, с которым все отлично и стабильно работает. Фреймворк актуальный, поддерживаемый, стабильный, удобный. Другие возможные варианты нам пробовать не приходилось, так как XCUITest соответствует всем нашим требованиям.
Вопрос 2. Как вам живется с автоматизированными регрессами?
За два года, что мы живем с автоматизированным регрессом, у нас надежно устаканился недельный релиз-трейн. Релизы регулярно отправляются в прод без проведения ручных регрессов благодаря количеству, качеству и, главное, доверию к автотестам.
Помимо того, что автотесты запускаются на релизных ветках, весь набор автотестов всегда прогоняется на фиче-ветках разработчиков перед мерджем. В девелоп/мастер не допускается код, который уронил тесты. Благодаря этому мы поддерживаем стабильность девелопа, мы уверены в нем и можем отрезать релизную ветку в любой момент.
Для тестировщика автоматизированный регресс может означать больше свободного времени для более важных и полезных задач — это, например, написание новых автотестов, увеличение стабильности существующих, развитие своего направления и тому подобные крутые задачи.
Вопрос 3. Много ли времени уходит на поддержку автотестов?
Поддержка автотестов встроена в наши процессы разработки. Как это работает — каждую неделю назначается дежурный тестировщик, одной из задач которого является следить за стабильностью тестов. Если тест упал, дежурный должен разобраться в причине падения и назначить ответственного на фикс. Если тест упал из-за собственной нестабильности — задача на тестировщика, если тест нашел баг — на разработчика, код которого повлиял на этот автотест. По опыту, чаще всего это не занимает много времени — один тестировщик тратит несколько часов за неделю.
Более сложные задачи — развитие, улучшение и оптимизация, фиксы инфраструктуры. Такие задачи идут наравне с разработкой продуктового функционала и имеют соответствующий флоу (проработка, декомпозиция, оценка, разработка и тд). Это случается не слишком часто, в среднем раз в квартал на каждую платформу. Тут важно отметить, что чаще всего это не самые высокоприоритетные задачи, и делаются они, когда у команды появляется на это ресурс.
Если всё четко настроить, научиться работать с флакующими тестами и по-максимуму их не допускать, то поддержка автотестов занимает мало времени и приносит много пользы.
Вопрос 4. Насколько сложно найти мобильного автоматизатора?
Порой сложно найти просто хорошего мобильного тестировщика с релевантным опытом, а с опытом автоматизации в конкретном стеке технологий дела обстоят еще сложнее.
В мобильные команды hh.ru мы обычно ищем просто крутых ручных тестировщиков, которые хотят развиваться в сторону автоматизации. Во время собеседований базовые знания в программировании, конечно, являются плюсом, но не решающим фактором. Автоматизации мы готовы обучать у себя. А вот что действительно важно — чтобы человек стремился развиваться, умел и хотел обучаться и был проактивным в этих моментах. Конечно, сложно точно определить такое во время собеседований, но и не совсем невозможно.
Вопрос 5. За сколько тестировщик превращается в автотестировщика
Опять же, по нашему опыту, мы нанимаем человека без опыта автоматизации и на испытательный срок (3 месяца) ему ставится задача — написать свой первый автотест на любую из платформ, которая ему понравится больше или покажется проще. И у нас еще никто не провалил испытательный срок.
Естественно, большую роль играет то, что человек пишет автотесты не совсем с нуля. У нас уже есть и готовые автотесты, которые можно смотреть и писать по аналогии, и люди, которые готовы помогать и отвечать на вопросы.
По итогу за 3 месяца мы получаем человека, который уже понимает, как писать автотесты минимум для одной из платформ. Следующим шагом будет написать такой же тест для второй платформы. Еще через 3-4 месяца мы получим самостоятельного автоматизатора мобильных приложений под обе платформы, которому еще какое-то время, возможно, нужна будет помощь с какими-то сложными вещами. Но вот свободно писать легкие автотесты под обе платформы он будет уже через полгода.
Вместо заключения:
Эта статья — продолжение серии ответов на вопросы про автоматизацию тестирования. Дальше нас ждут заключительные ТОП-5 вопросов начинающего автоматизатора про автотесты. Поговорим о флаковании, стабильности и баги с прода.
А чтобы не пропустить новые видео, статьи и прочие новости, подписывайтесь на наш новостной канал в телеге и канал с охэхэнными историями на youtube. Также вы можете задать вопросы нашим инженерам по любым темам в комментариях, в телеграм-чате с разработчиками hh или в личку.
Маленький опрос для большого исследования
Мы проводим ежегодное исследование технобренда крупнейших IT-компаний России. Нам очень нужно знать, что вы думаете про популярных (и не очень) работодателей. Опрос займет всего 10 минут.
Пройти опрос можно здесь.
Stay tuned!
Ищем тестировщиков в четыре разных направления:
