ТОП-5 вопросов менеджера про автоматизацию |
08.11.2021 00:00 |
Автор: Ольга Кабанова, Senior Mobile QA Engineer, hh.ru Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Ранее мы уже выпустили статью с ответами на вопросы ручного тестировщика про автотесты (а также в формате видео). Продолжаем серию ответов: в этой статье мы ответим на 5 самых популярных вопросов менеджера про автотесты. Расскажем о том, сколько времени и ресурсов будет потрачено на автоматизацию, и как скоро она начнет приносить пользу. Видеоверсию можно посмотреть тут. Вопрос 1. Не замедляют ли автотесты разработку? Начнем с того, что в первую очередь автотесты мощно сокращают время на тестирование и регрессы, а значит помогают выпускать фичи в релизы быстрее. Но, действительно, иногда они увеличивают время разработки. Например, когда разработчик меняет покрытый автотестами функционал, в связи с чем приходится перед мержем своего кода править падающие автотесты. Чтобы это не становилось проблемой, при оценке и декомпозиции задачи нужно закладывать время на возможные фиксы автотестов. В идеале на таких встречах должен присутствовать тестировщик, который сможет сказать, какие автотесты могут быть затронуты новым функционалом. Тогда время задачи будет предсказуемым и не увеличится. Но чтобы это нормально работало, нужно, чтобы на проекте была стабильная инфраструктура, и автотесты падали по понятным причинам. Тогда разработчикам не придется тратить свое драгоценное время, чтобы в каждой задаче разбираться, из-за чего именно упал автотест — из-за его кода или из-за проблем на тестовом стенде. Вопрос 2. Можно ли писать 1 автотест сразу на обе платформы? Конечно, можно. Существуют кроссплатформенные фреймворки, и многие их используют. Но мы сразу выбрали для себя нативные, как более стабильные, надежные и легко поддерживаемые. В чем главные проблемы кроссплатформенных фреймворков?
Может показаться, что написать один кроссплатформенный автотест быстрее и проще, чем два нативных. Но на самом деле это не так. Во-первых, всё “сэкономленное” время в последствии может уйти на поддержку такого автотеста для двух платформ. Это может стать проблемой из-за обновляемой специфики разных ОС. Кроме того, часто поведение одной и той же фичи или кнопки может различаться для iOS и Android. Во-вторых, если при выборе между кроссплатформенным фреймворком и нативными, главным аргументом является “выучить один язык программирования проще, чем два”, не спешите принимать решение. Синтаксис языков Kotlin и Swift очень похожи (по-крайней мере, в вопросах написания автотестов). Написав автотест на одном из языков, вы без труда напишете точно такой же для второй платформы. Вопрос 3. Когда автотесты начнут приносить больше пользы, чем проблем? Ровно тогда, когда:
Даже если тестов совсем немного, но они уже гоняются хотя бы перед мержем ветки разработчика, то это уже польза: минус какое-то количество ручных проверок и гарантия того, что ваше приложение как минимум запускается. Вопрос 4. За сколько месяцев можно прийти к 100% покрытию? Вопрос 100% покрытия — очень скользкий. Не хочется вдаваться в бесполезные споры о том, существует ли оно вообще и нужно ли к нему стремиться. Но поскольку его задают очень часто, давайте разбираться. Во-первых, стоит рассматривать покрытие каждой фичи отдельно. Во-вторых, глобально ответ на вопрос “на сколько у тебя покрыта эта фича” будет основываться на опыте и знании продукта тестировщика. Оценивая покрытие фичи, я рассуждаю следующим образом:
Также добавлю, что не все фичи в принципе нужно автоматизировать. Иногда трудозатраты на автоматизацию какой-то невероятно сложной проверки сильно преувеличивают возможность один раз перед релизом быстро проверить ее руками. Чтобы не оставлять вопрос менеджера без ответа — выявляем среди всей функциональности приложения наиболее критичный и в нём смотрим, какое количество позитивных и негативных проверок нам нужно автоматизировать в первую очередь, чтобы быть уверенными, что функционал работает. Далее смотрим какое количество тестировщиков сколько времени готовы уделять автоматизации и считаем, как долго мы будем это автоматизировать. Вопрос 5. Сколько нужно тестировщиков, чтобы автоматизировать весь проект? Расскажу историю об автоматизации мобильных приложений в hh.ru. В разные периоды времени у нас было от 2 до 4 тестировщиков на всё мобильное направление. Примерно за год мы пришли к практически полному покрытию регрессов на обе платформы. И это с учетом того, что мы продолжали тестировать функционал руками и проводить ручные регрессы, а на андроид дважды переезжали на новый фреймворк. В итоге, кстати, мы остановились на Kaspresso, с которым тесты стали сильно стабильнее и проще в написании. Каждый переезд был большим объемным рефакторингом, так как до этого мы уже успели написать какое-то значительное количество автотестов. Но тем не менее, за один год регрессы были автоматизированы. Иными словами, любым количеством тестировщиков можно автоматизировать проект, если выделить на это достаточно времени. Но возникает вопрос: как тестировщику успевать и руками тестировать, и автотесты писать? Иногда это действительно сложно. Особенно если идет большой поток нового функционала, который срочно нужно тестировать. Всем хочется успеть в релиз, и задачам ставят больший приоритет. Знакомая ситуация. Что делать?
Мы такое практикуем, когда у тестировщиков завал с ручным тестированием, и это работает. Для автоматизации можно выбрать день после релиза, когда уже ничего не горит, и тестировщик с чистой совестью может писать автотесты, не отвлекаясь на другие задачи. Вместо заключения: Эта статья — вторая из серии. Дальше нас ждут:
Подписывайтесь на наш новостной канал в телеге и канал с охэхэнными историями на youtube, чтобы не пропустить новые видео, статьи и прочие новости. А вопросы нашим инженерам по любым темам можно задать в комментариях, в телеграм-чате с разработчиками hh или в личку. |