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

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

С чего вообще начинается работа QA? Первым делом он садится за документацию, потом оценивает готовность проекта, попавшего ему в руки, по следующим пунктам:

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

Согласитесь, зачем проверять как работает приложение (речь про нефункциональное тестирование: performance, security, usability…), если оно в целом не выполняет возложенных на него функций?

После функционального тестирования идем проверять проблемные места в мобильных приложений с учётом их особенностей. О них дальше и пойдет речь. Разберем и Android, и iOS.

Согласитесь, каким бы ни было крутым приложение, такой косяк несомненно оставит негативный осадок. Поэтому, при тестировании мобильного приложения, это стоит проверить в первую очередь.

Каждый сам выбирает цветовую тему. Кто-то делает это ради удобства, а кто-то — ради экономии заряда батареи. К слову:

Вернёмся к тестированию тёмного/светлого режима.

Это, кстати, официальное моб.приложение JBL. Обе соседствующие кнопки в неактивном состоянии, но одна из них почему-то практически не видна. К слову, владельцам данной колонки и 13 андройда немного не повезло, т.к. с последним обновлением к приложению ни в какую не подключиться…

Как отображается набираемый текст в инпутах? Например, с
Xiaomi была такая ситуация. Dark Mode впервые показали в MIUI 11, а уже в MIUI 12 появился режим Dark Mode 2.0. Но тёмная тема работала адекватно не во всех приложениях. Так, в Facebook и Snapchat люди ловили баги, где при запуске приложения фон остаётся белым, а цвет шрифта меняется с чёрного на белый. Соответственно, ничего не видно.

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

Думаете в Xiaomi пошевелились по выпуску хотфикса по данной теме? Не тут-то было) В Mi Community заявили, что т.к. Dark Mode неправильно работает только в сторонних приложениях. Компания Xiaomi исправлять это особо не спешит.

В моих же реалиях приходится сталкиваться с багами, когда в инпуте (поле ввода текста) на белом фоне вводятся белый текст, Выглядит это примерно вот так:

Что происходит, когда интернет слабый или вовсе пропадает, пока ты «гуляешь» по приложению или пытаешься оформить заказ, добавить в избранное?

Это прямо настоящая боль в тестировании в последнее время. Например, на определённых версиях Android в проектах фото не прикрепляется вообще.

Если рассматривать данную тему целиком, то важно учесть сразу несколько вещей:

Представим ситуацию, когда тестируем отправку файла в офисе с хорошим интернетом. Все классно, — и приложение улетает в прод. Юзер пытается сделать тоже самое в подземном переходе. Файл, возможно, и дошёл бы, но зафейлился по таймауту (т.е. запрос отвалился, т.к. время его жизни истекло). А ведь стоило всего лишь увеличить время ожидания по данному запросу с 30 секунд до 60 (зависит от потребности и типа прогружаемого файла).

Например, на Android прикреплять можно минимум 3 способами (через галерею, проводник и сделав фото).
Бывают проблемы, когда файл просто не прикрепляется.

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

Все эти подпункты можно объединить в одну ситуацию и привести пример часто-встречающихся багов:

Любой из результатов (не побоюсь этого слова) ужасен для пользователя.

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

После первого нажатия кнопок, таких как «Оформить заказ», «Отправить заявку», «Зарегистрироваться» и т.д. их надо отключать, чтобы нельзя было выполнить команду дважды, пока не получен ответ от сервера. Это можно проверять сразу, выполняя позитивный кейс. Главное — взять за привычку.

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

Какие баги могут встретиться на Вашем пути в этом кейсе?

Снова ситуация: Вы оформляете заказ, приложение отображает webview (веб-страничку банка) с формой для указания карты, пользователь сворачивает приложение, чтобы посмотреть фото своей карты, возвращается назад, а там этой странички уже нет. Что произошло? Создался заказ? Но я ведь его не оплатил… Снова создавать или писать в тех. поддержку? Ай, закажу в другом месте.

Осуществление возврата назад на Android отличается от iOS. Тут возможно ситуации, когда эта опция должна быть недоступна. Например:

Не забудьте уточнить, каким должно быть поведение, если находишься на одном из основных экранов и нажимаешь «Назад». Должен ли осуществляться выход из приложения, или только при двойном нажатии, или при одном клике вас должно возвращать на основной (главный) экран?

Поюзали приложение, отложили девайс в сторону, а через 1.5-2 часа продолжили пользоваться. На этом этапе частенько проявляются баги. В большинстве случаев — это краш приложения. Как правило, это связано с используемой библиотекой в приложении, либо с утечкой памяти.

Это всё хорошо в теории и в идеале всему этому надо следовать. Например, заглядывать в данный чек-лист как QA, так и самим разработчикам. Но, к сожалению, не всегда до этого доходят руки и на это есть время…

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