Чем отличается тестирование мобильных и веб-приложений

Деление web / mobile есть не только для разработчиков. Тестировщики, как правило, также любят работать с чем-то одним. И если вы только заступаете на этот путь и не знаете, что выбрать и в чем разница, то эта статья вам в помощь.

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

Сергей, mobile-тестировщик

Как пришел в тестирование

На это повлияли две причины. Во-первых, мне нравится изучать все новое, а цифровая сфера – это вызов для меня, так как изначально у меня гуманитарное образование. Во-вторых, меня всегда удивляли сбои в работе приложения. В такие моменты я думал: «Как же это проглядели?» Как показал опыт: это очень реально.

Задачи тестировщика мобильных приложений

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

Почему нравится тестировать мобильные приложения

Я работаю с приложением, которым будут пользоваться другие люди, причем не пару человек из моего окружения, а многие тысячи. Это необычное чувство, когда ты тестируешь приложение, которое у всех на слуху, и узнаешь первым новые фишки, особенности, возможности. И получается так, что тестировщик – последнее звено в выпуске приложения. Именно он проводит итоговое тестирование и дает добро на заливку в App Store и Google Play.

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

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

А однажды мне пришлось идти в магазин заказчика, чтобы проверить приложение. Изначально проблема была такая: штрих-код для начисления бонусов обновлялся каждые 7 минут. Но если пользователь открывал приложение (например, в начале очереди на кассу) и 7 минут не трогал телефон, то в базе штрих-код обновлялся, а на экране телефона нет. И получалось, что, когда покупатель подходил к кассе, его штрих-код переставал работать. В итоге баг починили, и мне нужно было это проверить. Тестировалось так: я отправился с тестовым iPhone с включенным экраном в магазин (категорически нельзя было касаться экрана), семь минут гулял, ожидая, когда в приложении обновится штрих-код, и только потом шел к кассе. Реакция охраны и других посетителей запомнилась надолго.

Или как-то нам требовалось подружить наше приложение с приложением Google Fit, чтобы пользователь получал дополнительные бонусы за шаги. Догадались, как оно тестировалось? :-)

Это только часть примеров. Представить такие нетривиальные и интересные задачи в web-тестировании невозможно!

Сложность тестирования мобильных приложений

Смартфоны и планшеты – сложные устройства. С каждым их обновлением расширяется программный и аппаратный функционал. Очень часто они используют дополнительные девайсы: наушники, сим-карты, bluetooth-устройства, стилусы, внешние аккумуляторы и так далее. При тестировании нужно учитывать такие моменты. Приходится отвечать на вопросы: как поведет себя приложение, если телефон подключить к кабелю, а если его использовать без сим-карты и другое. И эти «если» нужно учитывать постоянно.

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

При тестировании web-приложений и сайтов, все осуществляется в пределах монитора стационарного компьютера или ноутбука. И только иногда смотрят на смартфоне или планшете. А вот при тестировании мобильных приложений рабочее место выглядит так: компьютер, несколько устройств, паутина различных кабелей. Порой и кружку чая некуда поставить.

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

Вот пример. Смартфоны Xiaomi сейчас очень популярны. В большинстве моделей используется фирменная оболочка MIUI. Перед релизом приложение тестируется, но предусмотреть все варианты невозможно. Как-то у нас после релиза всплыл грубый баг: при нажатии на определенную кнопку в приложении его работа аварийно завершалась. Оказалось, что этот баг только на устройстве Xiaomi Redmi Note 5A Prime, которая использует оболочку 10.2.1! На 10.2.0, 10.2.2 и других все работало. Для этой проверки пришлось даже подключать смартфоны близких людей.

Тестировщик в отделе мобильной разработки несет бóльшую ответственность, по сравнению с отделом web-разработки. Исправить «очепятку» у последних – это дело пары минут. В мобильном приложении на это понадобится пару дней, потому что после внесения правок обязательно надо проверить все заново, а потом подождать несколько дней, когда исправленное приложение появится в магазинах.

Заключение

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

Сергей, web-тестировщик

Как пришёл в тестирование

По образованию я самый настоящий айтишник, и в далёком 2010 году закончил технический факультет вуза. Но пошёл работать не совсем по специальности: кривая завела в далёкую от разработки сферу – рекламу и медиа. В итоге уже на четвёртом десятке лет я окончательно осознал: «Больше всего в жизни я хочу вернуться к истокам. Я хочу работать в айти. Я вижу себя только там и готов на всё, чтобы туда вернуться».

За долгие годы всё изученное в универе забылось. И как заново и с нуля войти в айти? В интернете пишут, что быстрее и проще всего через тестирование. Ну что же, через тестирование – значит через тестирование. Я посчитал свои денежные накопления, определил приемлемый срок на обучение, бросил работу, купил курсы обучения на тестировщика и приступил к изучению.

Задачи тестировщика web-приложений

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

Почему нравится тестировать web-приложения

Я люблю, когда всё работает как надо. Вы, наверняка, тоже. Вот зашли вы на какой-то обучающий сайт. Он очень полезный, там куча нужной вам информации, но почему-то не работают видеоуроки – нет кнопочки Play. А у вашего друга всё работает.

В итоге вы с неохотой ставите себе дополнительный браузер как у друга только ради того, чтобы смотреть видеокурсы на этом сайте. А позже, решив досмотреть урок с мобилки в метро, узнаёте, что в мобильной версии видеоуроки тоже не работают. Обидно и досадно, правда?

А теперь представьте, что лично вы можете влиять на качество и работоспособность подобных продуктов. Делать так, чтобы они работали всегда и везде, приносили людям радость и пользу. А вам за это ещё и хорошо платят. Круто? Круто!

Для меня тестировать web проще и вместе с этим интереснее. Мы не сталкиваемся с главной болью mobile-тестировщика: большой парк устройств и операционных систем, особенно для Android.

Сложность тестирования web-приложения

Продемонстрирую на одном простом примере. Допустим, вас взяли тестировщиком на проект. Что за проект и как конкретно он должен работать? Вам нужно это узнать.

Любая команда использует в работе специальные инструменты, набор которых определяется особенностями проекта или привычками. В нашем случае требования к проекту хранятся в системе Confluence. Вам надо её освоить и изучить документацию.

Теперь вы знаете, что делаете сайт, который должен показывать актуальное количество серых зайцев в лесу. Вы заходите на этот сайт с какого-то браузера, а количество зайцев не отображается. Казалось бы, вот он – баг. Надо его просто показать разработчикам, а они все починят. Но вы выясняете, что баги нужно заводить, например, в программе Jira по определённым правилам. Теперь надо изучить этот инструмент и стандарты оформления багов. Так вы узнали, что в команде хорошим тоном считают не просто указание на баг, но и его локализацию с подтверждениями.

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

Оказывается, при запросе сервер возвращает 500-ую ошибку. Проблема локализована. Скриншот ответа сервера из консоли приложен к багу в качестве подтверждения. Пока всё хорошо.

Позже из Jira пришло сообщение, что баг пофиксили. Значит, надо его перепроверить. Вы заходите на сайт и видите, что в лесу 42 серых зайца. Всё работает, как надо? Точно? Лучше проверить. В документации описана логика работы сервера. Оказывается, число зайцев ежедневно заливается в нашу базу данных из общей базы данных всех лесных животных.

Проверим нашу базу данных. Для этого потребуется доступ к базе и навык написания запросов на каком-нибудь SQL-подобном языке. В базе вы видите записи о зайцах и, в частности, их цветах. Выполнив запрос на подсчёт всех зайцев, вы получаете число 42. Но ведь наш сайт должен считать только серых зайцев. Выполнив другой запрос с учётом цвета, вы узнаёте, что серых зайцев на самом деле всего 10. Новый баг с приложенным скриншотом результатов запросов уходит к разработчикам.

Наконец, ваш сайт показывает количество именно серых зайцев. Казалось бы, теперь всё точно работает как надо. Но давайте проверим ещё одну вещь – актуальность количества зайцев. Зайцы приходят из других лесов и уходят в другие леса каждый день. В документации говорится, что наша база данных обновляется каждый день и подгружает данные из другой, общей, базы. Надо заглянуть и в неё. Если в ней тоже 10 серых зайцев, то всё должно быть хорошо.

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

Все описанные выше проверки не должны забываться и теряться. А ещё их результаты должны явно где-то отображаться. Для этого тоже существуют свои специальные инструменты. Например, Allure – программа для управления тестовой документацией. В нём можно писать свои тесты, формировать из них планы и запускать наборы тестов. При необходимости вы сможете актуализировать тесты, убирать устаревшие и добавлять новые. Таким образом вы будете уверены в том, что тестирование всё контролирует и ничего не упускает.

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

Заключение

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

В итоге

Тестирование web и mobile отличается разным типом задач.

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

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

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

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

Но самый лучший вариант – это попробовать то и другое и выбрать, что по душе ;)