Псс… Тестирование нннадо?

Мелкие баги могут испортить впечатление от релиза, а серьезные дефекты — привести к финансовым потерям. Где искать QA-инженера в штат? В каких случаях тестирование бесполезно? Как выстроены процессы в агентстве по тестированию? Расскажу на примере testCloud.

Начнем с того, что не все знают, кто такой тестировщик и с чем его едят.

Тестировщиков в России часто называют QA-инженерами (от английского Quality Assurance), хотя, строго говоря, это не одно и то же. Но для упрощения ниже будем использовать эти названия как синонимы.

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

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

Напротив, для QA-инженеров тестирование – это главная цель. Они проверяют разнообразные аспекты продукта: от безопасности персональных данных до процесса оформления заказа в интернет-магазине.

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

К тому же QA – это не просто про ошибки. QA-инженеры смотрят на продукт глазами пользователя и опираются на лучшие практики UX/UI. Поэтому они дают рекомендации, исходя из пользовательского опыта и ожиданий – в то время как программисту бывает сложно абстрагироваться от кода и увидеть продукт со стороны.

Глобально, тестирование – это одна из ключевых стадий разработки ПО. Но, конечно, бывают исключения. Тестировщики и правда не пригодятся в следующих случаях.

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

Либо ваш продукт может быть очень простым: скажем, одностраничный лендинг с несложной формой заявки. Да, нужно, чтобы форма работала и все элементы отображались корректно – иначе лендинг просто оттолкнет пользователей. Но проверить такой минимум функций можно силами дизайнеров и разработчиков – для тестирования в этом случае практически нет задач.

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

Вариант первый – эффективный, но времязатратный.

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

Вариант второй – надежный, но трудоемкий.

Можно нанять тестировщика в штат. Для этого стоит обратиться за рекомендацией к коллегам или разместить вакансию – на своем сайте либо на популярных рекрутинговых площадках (hh.ru или Хабр.Карьера). Что хорошо при таком подходе – к вам в компанию попадает уже состоявшийся специалист, который поможет улучшить процессы за счет своего опыта. Минусы – те же, что и при найме любого сотрудника: нужно выделить время на просмотр резюме и собеседования, провести онбординг новичка. К тому же всегда есть риск, что он не сработается с командой.

Вариант третий – простой, но рискованный.

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

Вариант четвертый – удобный, но не универсальный.

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

Наше агентство занимается тестированием уже несколько лет. Работаем с крупными продуктовыми компаниями, небольшими стартапами и студиями разработки.

Одним нужна независимая экспертиза продукта, когда есть сомнения в качестве разработки. Другие просто не хотят собеседовать 123 кандидата с hh.ru. У третьих уже есть свои тестировщики, но они хотят усилить команду во время сложного спринта. Наконец, четвертые не уверены, что им нужен отдельный специалист по тестированию и берут человека «на пробу».

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

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

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

Подготовка

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

Они доверили нам тестирование приложения Royal Flowers, разработанного для крупной сети цветочных магазинов. Нашей задачей было проверить админ-панель для менеджеров и флористов, а также приложение для пользователя. Сроки сжатые – на все тестирование три дня.

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

Команда

Под каждый проект мы собираем свою команду. Часть ребят – у нас в штате.

Часть привлекаем по проектной занятости. Например, можем ориентироваться на конкретные локации или часовой пояс: география наших QA – от Испании до Таиланда.

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

А еще в нашем распоряжении устройства с различными мониторами и операционными системами, в том числе старые и редкие модели. Например, в коллекции iOS — смартфоны от iPhone SE до iPhone 15 Pro Max. Если не нашлось «живого» устройства, пользуемся BrowserStack – в отличие от эмуляторов этот сервис позволяет удаленно использовать реальные смартфоны и компьютеры.

В случае с Royal Flowers все было достаточно стандартно – мы проверяли, как работает само приложение на смартфонах, а админ-панель тестировали на планшетах и ноутбуках. Использовали операционные системы iOS, Android, macOS и Windows.

Доступы

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

Если тестовых контуров нет – работаем как есть, соблюдая все установленные ограничения. Например, не перегружаем базу данных, отправляя текст первого тома «Войны и мира» в чате техподдержки, и не регистрируем пользователей с именем! W% жА, Lц}}Мй. В общем, стараемся тестировать по принципу «не навреди».

В случае с Royal Flowers нас попросили проверить версию продукта, которая уже доступна пользователям. Но оформлять заказы нам разрешили только в специально отведенном магазине на планете Марс :)

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

Чаще всего у заказчиков есть макеты в Figma – запрашиваем доступ и к ним.

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

Инструменты

Их набор варьируется от проекта к проекту – с учетом пожеланий заказчика. Можем работать с теми инструментами, которые у заказчика уже есть, а можем использовать свои и предоставить к ним доступ. Это быстро и бесплатно.

Для проекта Royal Flowers мы создали доску в Miro для чек-листа с описанием проверок, канбан-доску в ClickUp для баг-репортов. Также сделали отдельный чат в Telegram для общения с заказчиком, добавили туда разработчиков и проджекта. В таких чатах никогда не пишем по пустякам, задаем только важные вопросы.

Затем мы составили стратегию тестирования и подробный чек-лист проверок в Miro – он помогает ничего не упустить во время работы. По запросу мы можем передать чек-лист заказчику, чтобы его в дальнейшем могли использовать разработчики.

Фух! Тестирование

Если в процессе мы сталкиваемся с проблемой, которая не позволяет нам протестировать какой-то функционал, обязательно задаем вопросы заказчику. Например, в случае с Royal Flowers товары, которые мы создавали в тестовом магазине, не отображались в приложении у пользователя. Поэтому проверить, оформляется ли заказ, было невозможно. Мы оперативно решили эту проблему на созвоне с командой разработки.

В среднем мы находим порядка 70 багов на каждом проекте. Вот несколько любопытных примеров из Royal Flowers [напомним, что приложение уже доступно обычным пользователям]

• Если положить товар в корзину, а затем начать оформлять заказ, предварительно не авторизовавшись, то пользователя перебрасывает обратно в корзину, причем выбранный им товар дублируется. Когда покупатель снова переходит к оформлению без авторизации — появляется еще один дубль товара, и так можно ходить кругами до бесконечности :)
• Еще один неприятный для пользователя баг заключается в том, что можно удалить собственный номер телефона из личного кабинета. При этом не появляется никаких уведомлений, чем это грозит. По факту, профиль полностью удалялся со всеми личными данными и заказами. А повторно зарегистрироваться с тем же номером телефона уже нельзя.
  
• Наконец, пример из админ-панели. Вечно занятой администратор может по неосторожности создать товар, не указав цену, — и сохранить его в каталоге. Система никак не предупреждает об ошибке. Самое неприятное — такой товар за 0 денежных единиц появляется в приложении у пользователя, но не виден в админ-панели. Значит, администратор, скорее всего, даже не заметит и не поправит ошибку.
  

Баг-репорты и рекомендации по улучшению UX/UI заводим на канбан-доску. Стараемся писать их так, чтобы самый невыспавшийся разработчик сразу понял, в чем дело. В каждом баг-репорте – шаги воспроизведения, скриншот или скринкаст ошибки. Для удобства навигации пользуемся тегами, например, «admin», «user», «iOS», «API», – так разработчик сможет отфильтровать баги по определенному критерию. Если баг воспроизводится только на Windows 11 Pro в браузере Opera – обязательно укажем и это.

Результаты

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

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

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

______________________________

Это был рассказ о том, как мы тестировали приложение Royal Flowers в testCloud. В будущем напишем про процессы и на других проектах.

А пока расскажите в комментариях, что еще можно сделать, чтобы команда тестирования помогала, а не мешала разработке?