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

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

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

Новички от 25 до 40 тысяч рублей, среднего уровня в 40-100 тысяч рублей, опытные QA–инженеры от 100 тысяч рублей до 161 тысячи рублей.

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

Зачем нужно тестировать? Тут все просто: если выкатить на App Store и Google Play приложение, в котором тьма ошибок, все виснет и куча багов, то пользователи тут же оставят десятки гневных отзывов и низкие оценки. Другие зайдут, увидят все это и даже не станут скачивать.

Сам по себе процесс тестирования приложений довольно сложен. Нужно учитывать:

• десятки возможных разрешений экрана

• разные отличия в устройствах пользователей

• разные версии операционных систем

• у пользователя хороший wi-fi или другой тип подключения к интернету.

Специалисты–тестировщики выделяют несколько основных типов тестирования. У каждого из них своя цель.

• Нагрузочное тестирование или тест на производительность.

• Тестирование на восстановление.

• Интеграционное тестирование.

• Тестирование функциональности.

• Тестирование безопасности.

• Юзабилити–тестирование.

• Тестирование совместимости.

На каждом из них остановимся подробнее.

Это автоматическое тестирование, которое проверяет нагрузку на приложение: сколько пользователей одновременно могут в нем сидеть.

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

• Что случится, если приложение при средней нагрузке (среднем количестве пользователей) будут использовать несколько часов без перерыва. Как это скажется на работоспособности.

• Тестируют приложение в разных стресс–условиях.

• Проверяют, как все будет работать, если база данных серьезно вырастет. Будет ли все тормозить.

На этом тестировании проверяют, как приложение ведет себя при сбоях, которые появляются из–за прерванного интернета, «зависшего» или неожиданно отключившегося телефона. Может ли приложение быстро и успешно восстановиться. И может ли как–то противостоять этим проблемам.

Такое тестирование применяют не во всех приложениях. Да всем оно и не нужно. По–настоящему важно это для приложений, которые должны работать беспрерывно, 24*7.

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

Все эти сценарии проходят тестировщики. Смотрят, как поведет себя приложение с разных ситуациях.

Здесь проверяют, выполняет ли приложение свои функции, ради которых оно создавалось. Может ли пользователь провести в нем оплату.

Также смотрят на такие моменты:

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

• Тестирует, приходят ли человеку смс, когда он пользуется приложением, сохраняет ли их телефон.

• Смотрят, как работают кнопки для работы с соцсетями.

• Проверяют, дружит ли приложение с разными платежными системами.

• Тестируют нормально ли там все прокручивается на страницах.

• Убеждаются, что пользователям придут сообщения о ошибках, если что–то пойдет не так. Например, «ошибка сети», если соединение с интернетом оборвется внезапно

• Проверяют, не воюет ли приложение с другими, не забирает ли их память.

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

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

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

• Тестируют, требует ли система безопасности придумать надежный пароль, а не 12345.

На этом тестировании проверяют, удобно ли пользователю в приложении, все ли доступно и понятно в интерфейсе.

Например, проверяют, все ли кнопки в приложении нормального размера. А если пальцы крупные, человек сможет нажать?

Что пользователь сразу находит нужную кнопку и не путается.

Тестируют работу систем масштабирования: может ли пользователь что–то увеличить на экране приложения, а потом уменьшить, если нужно.

Что пользователь может отменять свои действия, возвращаться на предыдущие экраны.

Проверяют, все ли тексты в приложении пользователь видит, находят оптимальный шрифт.

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

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

Особенно проверяют такие моменты:

• Что текст и иконки приложения не выходят за рамки экрана.

• Что текст легко читается на экранах разного размера.

• Что разные функции устройства работают при включенном приложении.

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

Многие сценарии тестируют вручную. Но в последнее время все больше компаний переходит на автотесты. Плюсов у них много:

• Можно быстро найти ошибки и баги, прямо на начальном этапе разработки. И все быстро поправить.

• Ускоряют разработку.

• Экономят ресурсы.

Но есть и проблемы: нужно время (и навык), чтобы автотесты написать и внедрить. Потом их еще нужно будет поддерживать.

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

Можно выделить две группы тестировщиков мобильных приложений:

• Альфа–тестировщики. Они ищут ошибки и баги еще на стадии разработки приложения. Они, как правило, трудятся в штате компании.

• Бета–тестировщики. Они проверяют полную, уже готовую, версию приложения. Эту работу, помимо штатных тестировщиков, могут выполнять разработчики компании и сами пользователи. В последнем случае это работает, если люди знают продукт и с нетерпением ждут релиз.

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

Чаще других используют такие подходы:

• Один тестировщик на каждого разработчика.

• Один тестировщик на 10 разработчиков.

• 40% тестировщиков от численности команды разработки.

Многие компании, особенно те, что работают по методологии Agile, и вовсе обходятся без тестировщиков. Они работают по технике Test-driven development (TDD).

Если кратко, то тестированием занимается вся команда. А разработчики пишут автотесты на коды друг друга.

У тестировщиков есть разные специализации и функционал:

• Самая распространенная профессия — функциональный тестировщик (он же Manual QA engineer). Это как раз тот самый человек, который проводит ручные тесты. Он изучает специфику продукта, разрабатывает методы для проверки, все найденные ошибки и проблемы описывает в технической документации, часто на английском.

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

• Security–тестировщик. Этот специалист отвечает за проверку систем безопасности.

• Business intelligence. Тестировщик, который работает с большими объемами данных.

• Performance–тестировщик контролирует производительность программного обеспечения и нагрузку на приложения.

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

Эти специальности могут смешиваться внутри компании. Многие хотят иметь универсального тестировщика под рукой. Главная проблема среди тестировщиком в том, что один может круто придумывать тесты, но не уметь кодить. А другой — классный разработчик, который мог бы писать автоматические программы для проверки. Вот только он не разбирается в ручном тестировании. А значит, и придумывать хорошие автотесты ему будет сложно.

Новички получают от 25 до 40 тысяч рублей. В Москве — максимальная планка, в регионах — минимальная.

Тестировщики среднего уровня обойдутся компании в 40-100 тысяч рублей.

Опытные QA–инженеры приходят на зарплату от 100 тысяч рублей до 161 тысячи рублей.

За Head of QA придется выложить от 160 тысяч рублей в месяц.