Home

Автор: Ольга Кабанова, Senior Mobile QA Engineer, hh.ru
Оригинальная публикация

Всем привет! Я Оля, тестировщик мобильных приложений в 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 или в личку.

Обсудить в форуме