Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Ранее мы уже выпустили статью с ответами на вопросы ручного тестировщика про автотесты (а также в формате видео). Продолжаем серию ответов: в этой статье мы ответим на 5 самых популярных вопросов менеджера про автотесты. Расскажем о том, сколько времени и ресурсов будет потрачено на автоматизацию, и как скоро она начнет приносить пользу. Видеоверсию можно посмотреть тут.
Вопрос 1. Не замедляют ли автотесты разработку?
Начнем с того, что в первую очередь автотесты мощно сокращают время на тестирование и регрессы, а значит помогают выпускать фичи в релизы быстрее.
Но, действительно, иногда они увеличивают время разработки. Например, когда разработчик меняет покрытый автотестами функционал, в связи с чем приходится перед мержем своего кода править падающие автотесты.
Чтобы это не становилось проблемой, при оценке и декомпозиции задачи нужно закладывать время на возможные фиксы автотестов. В идеале на таких встречах должен присутствовать тестировщик, который сможет сказать, какие автотесты могут быть затронуты новым функционалом. Тогда время задачи будет предсказуемым и не увеличится.
Но чтобы это нормально работало, нужно, чтобы на проекте была стабильная инфраструктура, и автотесты падали по понятным причинам. Тогда разработчикам не придется тратить свое драгоценное время, чтобы в каждой задаче разбираться, из-за чего именно упал автотест — из-за его кода или из-за проблем на тестовом стенде.
Вопрос 2. Можно ли писать 1 автотест сразу на обе платформы?
Конечно, можно. Существуют кроссплатформенные фреймворки, и многие их используют. Но мы сразу выбрали для себя нативные, как более стабильные, надежные и легко поддерживаемые.
В чем главные проблемы кроссплатформенных фреймворков?
Это отдельно живущий от вашего приложения код. Если вам понадобится в нем что-то доработать или настроить под себя, то придется идти к другим разработчикам, делать запросы и ждать, пока они сделают и выпустят это на своей стороне, что не всегда удобно и продуктивно.
Частые проблемы при выходе новых ОС и баги. Нужно ждать поддержку со стороны разработчиков фреймворка, и это ожидание весьма непредсказуемое. Вы не знаете, когда всё поправят и оптимизируют, и когда оно у вас наконец заработает. То есть вы зависимы от других людей.
Возможно, выбранный вами кроссплатформенный фреймворк написан на языке программирования, который не знаком вашим разработчикам. Тогда помощь от них будет получить сложнее, если она вам вдруг понадобится. Также разработчики в этом случае не смогут писать и править автотесты самостоятельно.
Может показаться, что написать один кроссплатформенный автотест быстрее и проще, чем два нативных. Но на самом деле это не так.
Во-первых, всё “сэкономленное” время в последствии может уйти на поддержку такого автотеста для двух платформ. Это может стать проблемой из-за обновляемой специфики разных ОС. Кроме того, часто поведение одной и той же фичи или кнопки может различаться для iOS и Android.
Во-вторых, если при выборе между кроссплатформенным фреймворком и нативными, главным аргументом является “выучить один язык программирования проще, чем два”, не спешите принимать решение. Синтаксис языков Kotlin и Swift очень похожи (по-крайней мере, в вопросах написания автотестов). Написав автотест на одном из языков, вы без труда напишете точно такой же для второй платформы.
Вопрос 3. Когда автотесты начнут приносить больше пользы, чем проблем?
Ровно тогда, когда:
на вашем проекте будет настроена стабильная инфраструктура,
автотесты будут встроены в ваш CI/CD, а не запускаться локально у кого-то, когда об их существовании вспомнили,
автотесты будут падать приемлемое для вас количество раз, то есть не будут флаковать.
Даже если тестов совсем немного, но они уже гоняются хотя бы перед мержем ветки разработчика, то это уже польза: минус какое-то количество ручных проверок и гарантия того, что ваше приложение как минимум запускается.
Вопрос 4. За сколько месяцев можно прийти к 100% покрытию?
Вопрос 100% покрытия — очень скользкий. Не хочется вдаваться в бесполезные споры о том, существует ли оно вообще и нужно ли к нему стремиться. Но поскольку его задают очень часто, давайте разбираться.
Во-первых, стоит рассматривать покрытие каждой фичи отдельно.
Во-вторых, глобально ответ на вопрос “на сколько у тебя покрыта эта фича” будет основываться на опыте и знании продукта тестировщика.
Оценивая покрытие фичи, я рассуждаю следующим образом:
все позитивные проверки — это 60-70% от всего покрытия,
далее добавляем негативные проверки (всевозможные прерывания, сворачивания-разворачивания экранов, зероскрины и т.п.) — получаем 90%.
Оставшиеся 10% — это сложновоспроизводимые сценарии, зависимости от других фичей и т.д., которые покрывать либо вообще не стоит (подумайте, выдержит ли такую нагрузку ваш CI и стоит ли того время на поддержку таких автотестов), либо оставлять это на самую последнюю очередь.
Также добавлю, что не все фичи в принципе нужно автоматизировать. Иногда трудозатраты на автоматизацию какой-то невероятно сложной проверки сильно преувеличивают возможность один раз перед релизом быстро проверить ее руками.
Чтобы не оставлять вопрос менеджера без ответа — выявляем среди всей функциональности приложения наиболее критичный и в нём смотрим, какое количество позитивных и негативных проверок нам нужно автоматизировать в первую очередь, чтобы быть уверенными, что функционал работает. Далее смотрим какое количество тестировщиков сколько времени готовы уделять автоматизации и считаем, как долго мы будем это автоматизировать.
Вопрос 5. Сколько нужно тестировщиков, чтобы автоматизировать весь проект?
Расскажу историю об автоматизации мобильных приложений в hh.ru.
В разные периоды времени у нас было от 2 до 4 тестировщиков на всё мобильное направление. Примерно за год мы пришли к практически полному покрытию регрессов на обе платформы. И это с учетом того, что мы продолжали тестировать функционал руками и проводить ручные регрессы, а на андроид дважды переезжали на новый фреймворк. В итоге, кстати, мы остановились на Kaspresso, с которым тесты стали сильно стабильнее и проще в написании. Каждый переезд был большим объемным рефакторингом, так как до этого мы уже успели написать какое-то значительное количество автотестов. Но тем не менее, за один год регрессы были автоматизированы.
Иными словами, любым количеством тестировщиков можно автоматизировать проект, если выделить на это достаточно времени.
Но возникает вопрос: как тестировщику успевать и руками тестировать, и автотесты писать?
Иногда это действительно сложно. Особенно если идет большой поток нового функционала, который срочно нужно тестировать. Всем хочется успеть в релиз, и задачам ставят больший приоритет. Знакомая ситуация. Что делать?
Садимся.
Понимаем, что автотесты в недалеком будущем принесут нам максимум пользы и выделяем каждому тестировщику, например, один день в неделю под автоматизацию.
Мы такое практикуем, когда у тестировщиков завал с ручным тестированием, и это работает. Для автоматизации можно выбрать день после релиза, когда уже ничего не горит, и тестировщик с чистой совестью может писать автотесты, не отвлекаясь на другие задачи.
Вместо заключения:
Эта статья — вторая из серии. Дальше нас ждут:
ТОП-5 вопросов CTO про автотесты
ТОП-5 вопросов начинающего автоматизатора про автотесты
Подписывайтесь на наш новостной канал в телеге и канал с охэхэнными историями на youtube, чтобы не пропустить новые видео, статьи и прочие новости. А вопросы нашим инженерам по любым темам можно задать в комментариях, в телеграм-чате с разработчиками hh или в личку.
Маленький опрос для большого исследования
Мы проводим ежегодное исследование технобренда крупнейших IT-компаний России. Нам очень нужно знать, что вы думаете про популярных (и не очень) работодателей. Опрос займет всего 10 минут.
Пройти опрос можно здесь.
Stay tuned!
Ищем тестировщиков в четыре разных направления:
Комментарии (21)
amarao
16.09.2021 10:11-1Мне очень странно слышать слово "автотест". Тесты - это содержимое
tests/А уж кто их запускает - CI, или человек руками, или даже script exporter по расписанию - это дело десятое. И да, проект без тестов - это "набросок" (study), пока делаешь exploratory programming. Закончил прототип, начал к продакшену готовить - тесты.
.... кто-то вообще принимает изменения без тестов.
olgamsk4 Автор
16.09.2021 11:10+1Стоит уточнить, что по большей части я тут говорю про UI-тесты.
В настоящее время достаточно много проектов (особенно в мобильной разработке), которые выпускаются/разрабатываются без тестов. Не без тестирования, а именно без тестов. Такие проекты просто тестируются силами ручных тестировщиков.
Почему говорю, что тесты должны запускаться на CI.
Запускать тесты локально - не стабильно, можно пропустить этот момент, забить на какие-то фэйлы или пропустить их.
По расписанию - уже ближе к истине, но между двумя запусками могут случиться «множественные» мержи и потом нужно будет дольше разбираться, чьи изменения повлияли.
amarao
16.09.2021 11:20+1Стабильность локальных тестов - это одно из условий комфортной разработки. Мы когда работаем над проектами, условие "могу запустить сам, без CI" - обязательное. Потому что иначе development loop (попушить в гит, получить сообщение об опечатке через 20 минут) становится не tight, а для продуктивной работы должен быть tight.
Я бы даже сказал, что время, через которое программист получает сообщение об ошибке - главная метрика его продуктивности. Если ошибка в течение секунды-двух, то человек на пике своей продуктивности. Если через час-полтора, то человек делает 8 коммитов в день, из которых 7 - исправление опечаток.
olgamsk4 Автор
16.09.2021 11:39+1Для таких быстрых проверок существует статический анализ, который для своего проекта можно настроить максимально комфортно, и все подобные «опечатки» будут выявляться сразу. (У нас максимально быстро приходит сообщение об ошибках такого рода).
Так же для быстрой проверки, что ветка ничего не сломала есть юнит-тесты, которые мы запускаем на PR-ах. Это тоже достаточно быстрый способ узнать, что все ок и получить уже более существенные ошибки.
Разработчики, разумеется, гоняют юнит-тесты и стат. анализ локально.
UI-тесты это уже полная проверка всего приложения. Их не имеет смысла запускать на каждом коммите, это верно (по крайней мере полный набор). Но перед каждым мержем в девелоп уже стоит. Тут стоит еще сказать, что у нас не trunk-base.
Плюс то, что все эти тесты будут запускаться на CI не исключает возможности запустить эти же тесты локально. Все или какие-то отдельные, связанные с вашим функционалом. Это уже по желанию самих разработчиков.
Также для отладки мы сделали специальные планы на CI, в которых можно запустить не все тесты, а только помеченные аннотацией. Их часто используют для отладки
amarao
16.09.2021 14:43+1lint не способен найти опечатки. Он способен найти отклонения от стиля. Если я сделал
if configuration['litsen']:то никакой линтер не поймает такое. Однако, это тупая опечатка, которая может быть поправлена в течение 2-10 секунд если тест упадёт в течение секунды, и которая займёт 1 час 3 минуты, если CI сообщит о проблеме через час. Это называется tight loop, и он определяет продуктивность разработчика.
AlexeyALV
16.09.2021 11:40+2Нет ли тут путаницы между unit-тестированием, интеграционным и UI-тестами? Последние два вы, как разработчик, сомнительно, что делаете. Если только не один пишете весь проект
amarao
16.09.2021 14:46Я как девопс, пишу всё. И юнит, и интеграционные, и ui (если у наших продуктов есть ui), и более того, я очень хочу, чтобы интеграционные тесты можно было запускать локально. Не всегда возможно, но с максимом усилий, чтобы можно было.
Последний раз я писал интеграционные тесты для распределённой peer to peer VPN сети. Полное время поднятия системы (включая кластер из трёх серверов, три рабочие станции и три независимых сервера) занимало у меня примерно минут 5 на моей рабочей машине, плюс около минуты интеграционные тесты (добавить пользователя, проверить, что он может подключиться, забанить пользователя, увидеть, что он отвалился и т.д.). Это - tight loop. И это причина, почему моё желание иметь много денег находит отклик у работодателя.
Я мог бы всё это оставить непротестированным (сложно!), либо переложить на CI (час-полтора, и всё готово), но тогда задача была бы всё ещё в стадии отладки.
SerjV
16.09.2021 11:32+1Мне очень странно слышать слово "автотест".
Хм... А что тогда находится посредине между ручным тестом и автоматизированным?..
Между ручным и автоматическим еще понятно, как раз автоматизированный...
amarao
16.09.2021 11:39Ручной запуск тестов, не по расписанию. Обычно туда кладутся очень flaky тесты, либо тесты, требующие немалой компетенции, либо очень разрушительные тесты, которые человек знает когда можно запускать.
На самом деле все они - это сценарии, а проверка "работает или нет" уже обязательно хорошо описана. Если не описана - проект сырой и к продакшену не готовый.
SerjV
16.09.2021 12:16+1Я конечно прошу прощения, что домахиваюсь до формулировок, но вы как раз говорите тоже об автоматизированном тестировании. Автоматизированное что-то-там допускает участие человека, в отличии от автоматического, которое работает без него. И оба отличаются от ручного, где "программа" тестирования выполняется руками оператора.
Или вы хотите сказать, что автор статьи "топит" за автоматический запуск тестов, а надо, чтобы был выбор - вручную или автоматом?
amarao
16.09.2021 14:52-2Это очень малое различие. Если вы можете запустить тесты вручную, что вам мешает их в CI добавить?
Мой поинт был, что считать тестами "ручные", а автоматизацию считать вишенкой на торте, это всё равно, что считать, что автомобиль без тормозов, а тормоза - опция при покупке.
SerjV
16.09.2021 15:36+1Ну так UI, а иногда не только UI, на практике очень даже часто буквально руками тестируют, без автоматизации...
ivanych
17.09.2021 09:45Тут терминологическая путаница.
1. То, что вы называете "ручным тестом", на самом деле называется "ручное выполнение тест-кейса". Это процесс, глагол, если угодно.
2. Тест-кейс можно превратить в тест - скрипт, программа такая.
3. Этот тест можно запустить руками. Это то, что вы называете "посредине между ручным и автоматизированным".
4. Ну и наконец тесты можно запускать автоматически, в CI.
Вот пункты 2, 3 и 4 часто не заморачиваясь и не различая называют автотестами, бардак.
SerjV
17.09.2021 10:47Тогда надо подобные статьи начинать с определений, похоже.
Потому что наличие скрипта (п.2) предполагает использование автоматизации для тестирования, в отличии от п.1, где тестирование производится без автоматизации (ну не считать же автоматизацией использование компьютера в данном случае?).
И в контексте ссылки на предыдущию статью из этой - по-моему да, 2-4 все вместе попадают в категорию "автотесты", т.к. используют автоматизацию для тестирования, насколько я понял ту статью.
Но с другой стороны, ручной запуск тест-скрипта - по подобной логике является автоматизированным тестированием, а автоматический его запуск в CI - автоматическим, и промежуточное звено между ручным и автоматизированным отсутствует за ненадобностью...
По крайней мере в контексте UI. Но в контексте юнит-тестов я с трудом могу себе представить на практике тест, не использующий автоматизацию... Так что и с ним - ручной запуск это "автоматизация", без прямого участия человека - уже "автоматическое".
benavir
20.09.2021 10:22+2У меня возникло пару вопросов:
Примерно за год мы пришли к практически полному покрытию регрессов на обе платформы. И это с учетом того, что мы продолжали тестировать функционал руками и проводить ручные регрессы, а на андроид дважды переезжали на новый фреймворк.
Подскажите, а как часто осуществлялись релизы/какой объём задач ежедневно падал на плечи тестировщиков, что команда смогла написать автотесты на регресс за достаточно небольшой промежуток времени?
И второе:
Понимаем, что автотесты в недалеком будущем принесут нам максимум пользы и выделяем каждому тестировщику, например, один день в неделю под автоматизацию
Команда тестировщиков состояла из людей, которые имеют достаточно большой опыт в написании автоматизированных тестов?
Почему меня заинтересовали эти два момента: допустим, мы имеем достаточно крупную команию с достаточно частым циклом непрерывной интеграции. В команде есть один тестировщик и, допустим, 7 разработчиков, пишущих код. Задачи, поступающие на тестировщика могут быть разноплановыми: от тривиальной (орфографические правки) до сложных бизнесовых с неявными требованиями и сложной логикой. При таком темпе работ, ИМХО, шансы заавтоматизировать регресс, а в идеале ещё и покрыть автотестами выпущенный функционал, стремятся к нулю. А если у тестировщика недостаточно навыков в автоматизации (читай джун), то вероятность написания автоматизированных тестов ещё больше уменьшается. Как тогда качественно покрыть кодом регресс?
Согласен, что, чтобы перевести регресс в от ручных проверок в автоматизированные, не нужно нанимать целую команду автоматизаторов. Тут нужно взвешенное решение, основанное на том, справляе(ю)тся ли тестировщик(и) с потоком разработки и хватает ли у него(них) времени на написание кода.
olgamsk4 Автор
20.09.2021 11:29+1Предусловия у нас были такие:
Нас было 4 тестировщика на 4 мобильных приложения (по 2 приложения на 2 платформы) - 2 тестировщика уже умели автоматизировать, 2 пришли учиться автоматизировать с нуля. При этом уровень мануального тестирования у всех был мидл+.
Релизы были примерно раз в две недели (выпускали приложения попарно: первую неделю первое на обе платформы, вторую неделю - второе). Тогда, два года назад, релиз-трейн у нас был только в планах и еще не встал на рельсы. Но это скорее даже минус, так как многие задачи приходилось тестировать обязательно и срочно, чтобы выпустить релиз.
Разработчиков на 4 тестировщика было примерно человек 15, задач было достаточно много, и были все шансы закопаться в них на 100%, но мы сделали именно так, как я пишу в статье - для каждого тестировщика один день в неделю ставили автоматизацию первым приоритетом.
Ну и не знаю, насколько корректно писать об этом здесь же, но когда участвуешь в автоматизации регресса с самого начала, у тебя есть особый азарт и интерес этим заниматься, поэтому время на первые автотесты находилось очень часто у тестировщиков и в самые загруженные дни по остаточному принципу.
Стоит так же отметить, что да, какое-то продолжительное время покрываться автотестами будет именно регресс - устоявшийся, редко меняющийся, стабильный функционал. До покрытия автотестами нового функционала мы вот пришли только спустя полтора года.
На счет качества получаемых таким образом автотестов. Да, по началу они могут быть написаны кривовато и флаковать, но со временем тестировщик будет лучше понимать как всё работает, как написать лучше, как сделать так, чтобы меньше флаковало и работало стабильнее. То есть чем дальше, тем тесты будут лучше и качественнее. Плюс, автотесты должны проходить ревью от кого-нибудь, кто в этом разбирается. Тогда в код не будет просачиваться совсем уж что-то на джунском)
Мое мнение на счет 1 тестировщика на 7 разработчиков - тут всё реально, если разработчики помогут своему тестировщику с первыми автотестами и настройкой всего для автоматизации. Дальше тесты уже пишутся очень просто и быстро. Самое сложное всегда это начать. В нашем случае было просто во-первых потому что разработчики нам помогали, а во-вторых, что нас было 2-4, а не 1. Всегда была возможность договориться между собой, что один возьмет на себя чуть больше ручного, чтобы освободить время другому не отвлекаться и довести автотесты до пул реквеста.
Xanderblinov
21.09.2021 21:16+2@benavir от себя еще предложил бы вам хотя бы временно уменьшить нагрузку на тестировщика. Вообще 1 к 7 это еще хуже чем в известной картинке!
Как можно снять нагрузку? Можно найти много способов, например:
Отправить двоих разрабов разрабатывать фреймворк и инфру для автотестов (это убьет сразу же двух зайцев, кстати)
Взять на пару месяцев аутстаф тестировщика на мануальное тестирование, чтобы разгрузить Вас (мы, кстати, так сделали, когда запускали автотестирование на втором приложении)
Дождаться, когда команда уйдет в отпуск ( перед новогодними, например)
Удачи Вам, поговорите, со своим руководителям о балансе сил!
apachik
30.09.2021 16:53А сколько еще людей у вас задействовано для работы автотестов? кто поддерживает инфраструктуру? разработчики/девопсы? Большинство толковых ручников конечно можно научить пилить автотесты UI "по образцу". Но это до первой серьезной проблемы (или обновления ОС). Прошлую статью тоже прочитал, ответа на этот вопрос не нашел
olgamsk4 Автор
01.10.2021 11:32Поддержкой и настройкой тестовых сред у нас занимается отдельная команда. Это команда девопсов, состоящая из 5 человек, которая занимается всем тестовым бэкендом компании, железом и администрированием CI-сервера.
По факту из этой команды нам обычно помогает один человек, и в основном это настройки железа. Но это не совсем частые задачи, так что в целом времени на это у команды инфраструктуры уходит не много.
Всей мобильной спецификой инфраструктуры занимаемся мы сами. И тестировщики, и разработчики. На нас такие задачи, как настройка CI, скрипты и автоматизации под мобилки. В основном такие задачу попадают на платформенные кор-команды (2 разработчика с каждой платформы, но это, конечно, не единственное, чем они занимаются).
Ручные тестировщики, которые у нас постепенно превращаются в автоматизаторов, наравне с разработчиками берут задачи, связанные с инфраструктурой. Это одно из направлений развития.
sergeyns
Автотесты.. прочие модные смузи..
Перестаньте автоматом перенаправлять меня сайт перекрестка с вакансиями продавцов!
ivanych
Хехе, а вот если бы тут были автотесты, то ваш комментарий с ошибкой не добавился бы:)