Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. У нашей команды есть влог на ютюбе, где мы рассказываем о том, как разрабатывается наша мобилка. Теперь мы начинаем рассказывать еще и о том, как все эти разработки тестируются. Для заинтересованных мы создали отдельный плейлист, в котором будем рассказывать о тестировании и автоматизации.
В этой статье мы отвечаем на 5 самых популярных вопросов ручных тестировщиков про автоматизацию. Видеоверсию можно посмотреть тут.
Кому будет полезна статья?
развивающимся проектам, на которых еще нет автоматизации тестирования и которые начинают о ней задумываться
специалистам по ручному тестированию, которые хотят начать заниматься автоматизацией.
Вопрос 1. Зачем нужна автоматизация, если наши ручные тестировщики и так справляются?
Действительно, прежде чем вводить автоматизацию на проекте, потому что это “стильно, модно, молодежно”, и у всех оно есть, стоит учесть следующие факторы:
Как долго будет жить проект, каков его масштаб, насколько сильно и часто он меняется.
Оценить, насколько трудозатратно будет писать автотесты в каждом конкретном случае. Возможно, что автоматизировать ваш функционал будет гораздо сложнее, дольше и дороже, чем тестировать его руками.
Также, если на проекте ожидается “выпиливаем всё старое и пишем новое с нуля”, время автотестов еще не пришло.
Но если ваш проект:
стабильно развивается и растет
увеличивается количество разработчиков
приложение начинает обрастать новым функционалом
То прямо пропорционально начнет увеличиваться и время тестирования. Рано или поздно оно дойдет до критического момента, когда регресс будет занимать больше времени, чем велась разработка. Это значит, что пришло время задуматься об автоматизации тестирования.
Автотесты станут гарантией, что ничего из старого не отвалилось, пока разработчики делали новые крутые штуки. Особенно, если эти новые штуки делались в совершенно других частях кода. Ручные регрессы, в данном случае, это, конечно, хорошо, но тут и человеческий фактор, и замыленный глаз, и непредсказуемость мест, в которых могут всплыть баги.При этом ручное тестирование полностью никуда не уходит, так как новый функционал все еще будет проверяться руками. Нет смысла автоматизировать то, что возможно не взлетит и уже через неделю будет выпилено или отправлено на доработки.
Но вместо того, чтобы занимать ручного тестировщика написанием тест-кейсов на новый функционал, поддержку документации и постоянными регрессами, можно выделить ему хотя бы один день в неделю на автоматизацию, помочь на старте с настройками инфраструктуры, и уже через несколько месяцев у вас начнут гонять первые автотесты, ваши задачи станут в разы быстрее доходить до релизов а заодно станет больше уверенности в стабильности выпускаемого кода.
Еще автоматизированный регресс позволяет тестировщикам больше времени уделять полезным задачам, например, исследовательскому тестированию. Кроме того, появится лучшее понимание, как работает приложение под капотом, что точно пригодится даже в ручном тестировании.
Вопрос 2. Можно ли начать писать автотесты за один день?
Писать автотесты можно начать прямо в этот самый момент, но лучше с этим не торопиться и подойти к вопросу осмысленно.
Если на проекте еще не было автоматизации, то нужно обязательно начать с ресерча существующих инструментов, фреймворков, подходов. Почитать о том, с какими проблемами сталкиваются пользователи, и как быстро они решаются. Оценить все плюсы и минусы, выбрать самое подходящее, с чем будет легко и приятно работать. Цена ошибки на старте намного меньше, чем когда вы уже активно автоматизируете и вдруг понимаете, что выбранный вами фреймворк никому не удобен и совершенно вам не подходит.
Если вы никогда раньше не занимались автотестами, первое время может быть сложно.. Непросто начать писать автотесты сразу, если еще нет никаких примеров и не на что опереться. Благо, сейчас в интернете очень много различных статей с массой хороших примеров кода, которые можно брать, подстраивать под себя и разбираться, как они работают.
В конце концов, чтобы научиться автоматизировать, надо просто начать автоматизировать. Это действительно работает.
Идеально, если со стороны разработчиков будут те, кто готов на первых порах вам помогать разбираться в коде, отвечать на все ваши вопросы. В hh именно так и было — первое время, когда мы только начинали писать свои первые автотесты, мы просто заваливали наших ребят всевозможными вопросами. Благодаря им мы и пришли к тому, что имеем сегодня
Но вполне возможно, что у вашей команды не будет времени помогать вам с автотестами. К сожалению, такое возможно, и не стоит их за это винить. Если вы попали в такую ситуацию, не отчаивайтесь! Наша команда создала чат в телеграме, где мы готовы отвечать на все вопросы, связанные с разработкой, тестированием и автоматизацией мобильных приложений. Не бойтесь спрашивать, узнавать и начинать писать свои первые автотесты!
Также стоит отметить, что в интернете очень мощное комьюнити тестировщиков. В том же самом телеграме есть чаты, где 24/7 вам ответят на все вопросы и помогут разобраться.
Вопрос 3. Можно ли стать автоматизатором без опыта ручного тестирования?
Можно, если у вас есть опыт в программировании. В каких-то компаниях это действительно так и работает. Ручные тестировщики пишут тест-кейсы (шаги + ожидаемый результат), автоматизатор их берет и переносит в код. В принципе, такой подход вполне валиден и работает, но я вижу в нем некоторые недостатки.
Во-первых, когда сам пишешь автотесты на функционал, который хорошо знаешь, ты можешь по ходу добавлять какие-то проверки, которые мог пропустить во время написания тест-кейсов. Плюс знаешь другие автотесты, которые можно дополнить. Соответственно, тебе легче поддерживать актуальность автотестов.
Во-вторых, автоматизация тестирования — это интересно и полезно. Ты начинаешь изучать код, расширяешь свои знания о продукте, понимаешь, как всё работает изнутри. Это полезно и для ручного тестирования в том числе. Начинаешь чуть лучше понимать разработчиков.
Вопрос 4. Можно ли заставить разработчиков писать автотесты?
В теории, конечно можно. Но скорее всего они будут не сильно этому рады, да и вряд ли кто-то будет рад в принципе.
Во-первых, это замедлит саму разработку. Вместо того, чтобы писать код, разрабатывать продуктовый функционал, разработчики будут заниматься написанием автотестов.
Во-вторых, это дорого.
Ну и в-третьих, у каждого должна быть своя зона ответственности. Разработчики создают функционал, тестировщики — его проверяют. С автотестами все точно так же, как и в обычном тестировании. Вот юнит-тесты — да, зона отвествтенности разработчиков, но UI — это уже тестировщеское.
По факту, этот вопрос равен “Зачем нам тестировщики, если можно попросить разработчиков самим проверять то, что они написали?”.
Вопрос 5. Можно ли писать автотесты автоматически? Не хочется учиться программированию.
Попробовать можно. Мы пробовали. Для таких дел существуют рекордеры. Но те тесты, которые ими создаются — это монструозные и неподдерживаемые куски кода.
Возможно, это будет работать, если, допустим, в приложении есть какая-то кнопка, которая никогда не будет меняться. Не изменится ни путь до нее, ни ее функциональность и положение. Тогда код этого теста никогда не нужно будет менять, и пусть этот тест будет жить. Но увы, на практике так не работает. Тесты должны быть легко поддерживаемыми, понятными, читаемыми. Рекордером такого не добьешься.
Можно использовать рекордеры в каких-нибудь сложных местах приложения, чтобы посмотреть, как можно повзаимодействовать с каким-нибудь труднонаходимым элементом. То есть использовать его как помощника, как вспомогательный инструмент, но не как основное средство автоматизации.
Вместо заключения:
Данная статья является первой из серии. Далее нас ждут:
ТОП-5 вопросов менеджера про автотесты
ТОП-5 вопросов CTO про автотесты
ТОП-5 вопросов начинающего автоматизатора про автотесты
Интересно? Подписывайтесь на наш новостной канал в телеге и канал с охэхэнными историями на youtube, чтобы не пропустить новые видео, статьи и прочие новости. А вопросы нашим инженерам по любым темам можно задать в комментариях, в телеграм-чате с разработчиками hh или в личку.
Stay tuned!
Ищем тестировщиков в четыре разных направления:
