Как мы нашли 140+ багов в приложении и почему это стало опытом для всех

В статье вы узнаете:
- Как тестировщик с нуля разобрался в приложении без документации;
- Почему разработчики игнорируют исправление багов и что с этим делать;
- Какие уроки можно вынести из анализа огромного списка ошибок;
- Как полезно применять для себя разные роли, чтобы стать профессиональным тестировщиком.

Привет! Меня зовут Александр, и я работаю тестировщиком. Мне довелось протестировать мобильное приложение, связанное с туризмом. В этой статье я расскажу, как мы нашли 142 бага за один тестовый цикл, почему это стало настоящим детективным квестом и какие выводы из этого можно сделать для тестировщиков, разработчиков и заказчиков.

Предусловия:
Намерено скрыто название приложения и нет имён.
Проект под NDA.

Вас когда-нибудь интересовал вопрос — какие приключения могут ждать тестировщика приложения, связанного с туризмом? Мне довелось поучаствовать в таком проекте и готов поделиться своим опытом под углом юмора. Речь идет о приложении ИКС, которое было создано частной компанией, решившей покорить мир мобильного туризма.

ИП (индивидуальный предприниматель) решил, что пора сделать шаг в эпоху мобильных приложений, но, как это иногда бывает, столкнулся с некоторыми трудностями. Они наняли разработчика, который, возможно, был слишком увлечен своей работой, так как, судя по всему, сразу отправил приложение в продакшн в App Store и Google Play без дебажной сборки. Как говорится, «быстрее — значит лучше», но не в нашем случае.

Из документации у нас был только макет из Figma и представитель ИП, который делился своими высокими идеями. С чувством, что мы попали в какой-то квест, мы приступили к тестированию. Результат не заставил себя ждать — мы нашли 142 бага! Да-да, вы не ослышались. Почти как целая команда «Разноцветных Суперменов», которая расползлась по всему приложению.

Из них 20-30 были просто рекомендациями, которые могли бы сделать приложение более удобным и красивым. Представьте себе, как ИП смотрел на этот отчет — это было что-то вроде "Вместо одного чемодана вы вернули два".

После отправки отчета ожидание ответа заняло целых два месяца. Это время пошло на то, чтобы разработчики немного могли «подтянуться» и исправить то, что не успели или не смогли сделать с первого раза. Вернувшись на ревизию, мы, как детективы с увеличительным стеклом, вновь исследовали приложение. Но вот незадача: из 140 багов и рекомендаций осталось более 70%, которые стояли как стойкие оловянные солдатики.

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

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

За ночь порой можно придумать целую историю, а вот засыпая в уютной кровати рядом с близким человеком, я начал разрабатывать идеи для юзер-стори приложения ИКС. Глядя на потолок, я осознал одну неутешительную истину: я не гид и не турист. У меня нет ни опыта, ни специального образования для ведения экскурсий. Но я могу с помощью данного сервиса стать им.

Сначала я задумался о том, а что нужно для получения статуса гида? Загуглил и оказывается требуется целый набор документов: разрешение, госпошлина, экзамен и многое другое. И вот я представляю типичную ситуацию — разгар отпусков, и какой-нибудь Вася Пупкин из Таганрога, полный оптимизма, заходит в наше приложение. За два клика он создает аккаунт гида, выбирает популярные экскурсии и начинает накручивать отзывы.

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

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

Поняв всю серьезность потенциальной ситуации, я записал свои рекомендации для заказчика. Первое, что пришло в голову, — ограничить доступ случайным пользователям к созданию аккаунтов гидов.

Я предложил внедрить систему верификации гидов:
1. Пользователь загружает документы в приложение;
2. Модераторы проверяют данные в течение 48 часов;
3. После проверки гид получает отметку "Проверен". Это снизит риск мошенничества.
Это было бы немалое подспорье для обеспечения доверия пользователей к гиду, укрепление лояльности и, конечно, защита нашего заказчика от мошеннических схем.

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

Чему я научился на этом проекте?

1. Даже если нет документации, можно найти способы понять логику приложения;
2. Не стоит бояться фиксировать большое количество багов — главное, правильно их классифицировать;
3. Заказчикам важно понимать, что исправление багов — это не только про функциональность, но и про доверие пользователей.

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