Home

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

Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Ранее мы уже выпустили статью с ответами на вопросы ручного тестировщика про автотесты (а также в  формате видео). Продолжаем серию ответов: в этой статье мы ответим на 5 самых популярных вопросов менеджера про автотесты. Расскажем о том, сколько времени и ресурсов будет потрачено на автоматизацию, и как скоро она начнет приносить пользу. Видеоверсию можно посмотреть тут.

Вопрос 1. Не замедляют ли автотесты разработку?

Начнем с того, что в первую очередь автотесты мощно сокращают время на тестирование и регрессы, а значит помогают выпускать фичи в релизы быстрее. 

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

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

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

Вопрос 2. Можно ли писать 1 автотест сразу на обе платформы?

Конечно, можно. Существуют кроссплатформенные фреймворки, и многие их используют. Но мы сразу выбрали для себя нативные, как более стабильные, надежные и легко поддерживаемые.

В чем главные проблемы кроссплатформенных фреймворков?

1. Это отдельно живущий от вашего приложения код. Если вам понадобится в нем что-то доработать или настроить под себя, то придется идти к другим разработчикам, делать запросы и ждать, пока они сделают и выпустят это на своей стороне, что не всегда удобно и продуктивно.

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

3. Возможно, выбранный вами кроссплатформенный фреймворк написан на языке программирования, который не знаком вашим разработчикам. Тогда помощь от них будет получить сложнее, если она вам вдруг понадобится. Также разработчики в этом случае не смогут писать и править автотесты самостоятельно.

Может показаться, что написать один кроссплатформенный автотест быстрее и проще, чем два нативных. Но на самом деле это не так.

Во-первых, всё “сэкономленное” время в последствии может уйти на поддержку такого автотеста для двух платформ. Это может стать проблемой из-за обновляемой специфики разных ОС. Кроме того, часто поведение одной и той же фичи или кнопки может различаться для iOS и Android.

Во-вторых, если при выборе между кроссплатформенным фреймворком и нативными, главным аргументом является “выучить один язык программирования проще, чем два”, не спешите принимать решение. Синтаксис языков Kotlin и Swift очень похожи (по-крайней мере, в вопросах написания автотестов). Написав автотест на одном из языков, вы без труда напишете точно такой же для второй платформы. 

Вопрос 3. Когда автотесты начнут приносить больше пользы, чем проблем?

Ровно тогда, когда:

• на вашем проекте будет настроена стабильная инфраструктура, 

• автотесты будут встроены в ваш CI/CD, а не запускаться локально у кого-то, когда об их существовании вспомнили, 

• автотесты будут падать приемлемое для вас количество раз, то есть не будут флаковать.  

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

 Вопрос 4. За сколько месяцев можно прийти к 100% покрытию?

Вопрос 100% покрытия — очень скользкий. Не хочется вдаваться в бесполезные споры о том, существует ли оно вообще и нужно ли к нему стремиться. Но поскольку его  задают очень часто, давайте разбираться.

Во-первых, стоит рассматривать покрытие каждой фичи отдельно. 

Во-вторых, глобально ответ на вопрос “на сколько у тебя покрыта эта фича” будет основываться на опыте и знании продукта тестировщика.

Оценивая покрытие фичи, я рассуждаю следующим образом:

• все позитивные проверки — это 60-70% от всего покрытия,

• далее добавляем негативные проверки (всевозможные прерывания, сворачивания-разворачивания экранов, зероскрины и т.п.) — получаем 90%.

• Оставшиеся 10% — это сложновоспроизводимые сценарии, зависимости от других фичей и т.д., которые покрывать либо вообще не стоит (подумайте, выдержит ли такую нагрузку ваш CI и стоит ли того время на поддержку таких автотестов), либо оставлять это на самую последнюю очередь.

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

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

Вопрос 5. Сколько нужно тестировщиков, чтобы автоматизировать весь проект?

Расскажу историю об автоматизации мобильных приложений в hh.ru.

В разные периоды времени у нас было от 2 до 4 тестировщиков на всё мобильное направление. Примерно за год мы пришли к практически полному покрытию регрессов на обе платформы. И это с учетом того, что мы продолжали тестировать функционал руками и проводить ручные регрессы, а на андроид дважды переезжали на новый фреймворк. В итоге, кстати, мы остановились на Kaspresso, с которым тесты стали сильно стабильнее и проще в написании. Каждый переезд был большим объемным рефакторингом, так как до этого мы уже успели написать какое-то значительное количество автотестов. Но тем не менее, за один год регрессы были автоматизированы.

Иными словами, любым количеством тестировщиков можно автоматизировать проект, если выделить на это достаточно времени.

Но возникает вопрос: как тестировщику успевать и руками тестировать, и автотесты писать?

Иногда это действительно сложно. Особенно если идет большой поток нового функционала, который срочно нужно тестировать. Всем хочется успеть в релиз, и задачам ставят больший приоритет. Знакомая ситуация. Что делать? 

1. Садимся. 

2. Понимаем, что автотесты в недалеком будущем принесут нам максимум пользы и выделяем каждому тестировщику, например, один день в неделю под автоматизацию. 

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

Вместо заключения:

Эта статья — вторая из серии. Дальше нас ждут:

• ТОП-5 вопросов CTO про автотесты

• ТОП-5 вопросов начинающего автоматизатора про автотесты

Подписывайтесь на наш новостной канал в телеге и канал с охэхэнными историями на youtube, чтобы не пропустить новые видео, статьи и прочие новости. А вопросы нашим инженерам по любым темам можно задать в комментариях, в телеграм-чате с разработчиками hh или в личку.

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