Как выпустить приложение (почти) без багов

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

Никита Дьяков

Middle QA Engineer в Heads and Hands

Всем привет, я занимаюсь тестированием в студии разработки цифровых экосистем Heads and Hands. Расскажу о том, как устроен процесс тестирования мобильных приложений в студии — на них приходится большая часть наших проектов. В статье расскажу про этапы тестирования, инструменты и о том, где появляются баги и что считать таковыми.

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

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

Для себя роль тестирования я сформулировал следующим образом: «Вся разработка — это хождение по минному полю, состоящему из багов, отсутствия технического задания или его сырости, пожеланий заказчика, отсутствия времени». А суть QA — вдумчиво перемещаться по этому минному полю и ставить флажки не только на мины, но и на кочки, о которые может споткнуться команда.

Тестирование с точки зрения ISTQB

Добавим официальной документации. ISTQB — это международная сертификационная комиссия по тестированию программного обеспечения.

ISTQB выделяют следующие виды тестирования:

функциональное тестирование (functional testing);
нефункциональное тестирование (non-functional testing);
структурное тестирование (structural testing);
тестирование изменений (change related testing).

Кратко рассмотрим каждый вид тестирования.

Функциональное тестирование — оценка текущего состояния продукта на соответствие требованиям текущей технической документации и бизнес-требованиям. Мы имитируем реальное использование продукта и стараемся ответить на вопрос: «А оно вообще работает?».

Нефункциональное тестирование — пожалуй, самый вкусный, но тяжело перевариваемый вид тестирования: тут и нагрузочное тестирование, и UX, и стресс-тесты, и исследовательское и много чего еще.

Структурное тестирование — в документации проходит как тестирование «белым» или «серым» ящиком. Останавливаться на этом пункте не буду, так как в командах мобильной разработки код — это зона ответственности команды разработки.

Тестирование изменений — проверяем, точно ли исправили то, что чинили. Ну и всемогущий регресс — перепроверяем все, что было сделано, и выясняем две простые вещи: все ли работает и что было сломано, пока делали новое. Это боль команд со спринтами в две недели (ребята, если вы читаете это, знайте — морально я с вами).

Тестирование в жизни

Процесс тестирования обычно разделяется на три этапа:

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

Как мы боремся за качество

А теперь расскажу о том, как проходит тестирование у нас в Heads and Hands. Не будем разбивать процесс по видам и элементам, согласно вышеуказанному сухому документу ISTQB, а рассмотрим, какие цели стоят на каждом этапе создания продукта перед нашим QA-отделом.

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

Жизненный цикл разработки ПО

tproger.ru

Подготовительный этап

QA-отдел включается в работу на начальном этапе разработки продукта — работает с техническим заданием и дизайном, выдвигает предложения, которые по согласованию с заказчиком вносятся в соответствующие документы, находят потенциально рискованные места. Уточняем требования к объему тестирования и используемому инструментарию.

После «закрепления» технического задания и дизайн-макетов начинается подготовка чек-листов с последующим формированием тест-плана, где описываем объект тестирования, цели, ресурсы, оборудование и процессы.

Затем изучаем документ с требованиями к мобильному API и формируем коллекции Postman. Есть время — формируем валидацию.

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

Рассматриваем необходимость написания автотестов веб-фронта.

Этап тестирования

Проверяем задачи на фронте или бэке по мере их готовности. Если бек отстает от фронта, то QA-отдел должен оперативно подготовить моки и начать проверку фронта, если это технически возможно.

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

Параллельно отслеживаем изменения в техническом задании и дизайн-макетах, обсуждаем их с командой и заказчиком.

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

По мере созревания продукта ведем работы по написанию тестов доступности API, а по мере формирования набора основных юзер-кейсов создаются автотесты.

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

Поддержка, пересмотр, корректировка

В промежуточные этапы производим анализ тестируемого продукта «со стороны», оцениваем процесс, вносим коррективы и выдвигаем новые требования к тестированию. Вносим корректировки в чек-листы, автотесты.

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

О разделении на этапы

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

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

Основная цель QA-отдела — помочь команде в приемлемые сроки создать качественный продукт. Мало с чем можно сравнить ощущение удовлетворенности от процесса, когда кто-то пользуется результатом твоей работы. Когда нет NDA, можно гордо заявлять: «Я руки, голову и даже душу вложил в этот проект!».

Какие инструменты тестирования используем

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

Инструменты тестирования фронтенда

В 97% моих проектов фронтом выступали мобильные приложения платформ Android и iOS, 3% — браузеры, поэтому рассматриваю инструменты для тестирования мобильного фронта.

Charles Proxy — главный инструмент QA-специалиста, прекрасный и гениальный во всех смыслах.

Его преимущество в том, что мы реализуем принцип «человек посередине» и можем воздействовать на наш «черный ящик», оценить его реакцию на внешние раздражители. Мы можем:

Подменить http status ответа
Подменить описание на пустую строку
Изменить url сервера в запросе
Сделать замену по условию или регулярке
Замокать запрос, если он не готов на бэке, либо сформировать разные кейсы наполнения экрана
При необходимости сделать свой мок-сервер, но с определенными ухищрениями и ограничениями

Android Debug Bridge — мощный инструмент, который позволяет много чего натворить: начиная от скриншота и заканчивая злом в виде monkey-test. Минимальное, что должен знать каждый, как снимать логи: когда QA используют все инструменты сразу, то приложения почему-то падают.

MacOS — компания из Купертино, ребята хорошие, с мощной коммерческой жилкой. Если нужно сделать сборку на тестовый iOS-девайс вне очереди CI, снять логи с iOS, важно и красиво прийти на презентацию — тут только мак. Про презу полная правда, но для остального можно пользоваться любым Linux-дистрибутивом и Windows. Все инструменты, описанные в данной статье, кроссплатформенные, кроме Xcode.

Инструменты тестирования бекэнда

Postman — милый и ужасный в одном лице. Это целая инфраструктура: есть возможность за звонкую монету запускать тесты API по расписанию, есть красивый и вкусный монитор результатов.

Главная цель инструмента — послать запрос и получить ответ. Можно сделать запрос, получить ответ и сравнить со спецификацией на бек. А можно взять немножко JS, сдобрить минимальными познаниями в JSONschema, обернуть все это в tv4.validate и tests[""]=bool. Составление коллекции запросов с минимальными тестами на валидацию ответов сильно упрощают жизнь команде. Дело это пусть и хлопотное, но не сложное.

grpcUI — используем как средство визуализации запрос-ответ grpc протокола, пока нет инструментов, подобных CharlesProxy, которые работают стабильно и без заморочек. Существует такая замечательная штука как grpc-json-proxy, которая позволяет делать grpc-запросы через Postman — инструмент хороший, но не прижился. Если нужно просто проверить доступность методов, то в grpcURL есть необходимый минимум функциональности.

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

Хардкор/Go — пришли к тому, что автотесты API на Go — идеальный вариант. Конечно, Python проще в освоении, у него больше библиотек для осуществления тестирования, большое сообщество. Но Golang молод, красив, поддерживает многопоток из коробки, с ним можно реализовать полноценный тест-сервер с энд-поинтами, ожидающими клика в веб-лице или веб-хука.

Вспомогательные инструменты

Visual Studio Code — оптимальный инструмент для всего: от создания моков и просмотра jSON’ов до написания автотестов. Некоторые коллеги используют решение от JetBrains, но мне ближе VScode — там есть необходимый набор функций.

FireBase/Crashlytics/Аналитика — без аналитики, обратной технической связи от продукта сложно оценить правильность тех или иных решений не только со стороны тестирования, но и со стороны продукта в целом.

Командная строка — без баша никуда.

Как выпустить продукт без багов?

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

Пиксель наехал на пиксель, кнопка открывает не тот экран, порядок экранов не логичен или приложение падает — это, бесспорно, баги. А если заказчик считает, что продукт работает не так, как он хотел? Считаю, это тоже баг. Чтобы выпустить приложение без багов, банальное «надо лучше тестировать» не сработает.

Проджект-менеджер — это фильтр между командой и клиентом. Менеджер должен не просто узнать, чего хочет клиент, но и понять, каким должен быть продукт, чтобы улучшить бизнес клиента. Это сложно, за что ребятам отдельное спасибо.

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

Дизайн. От особенностей макета часто зависит количество багов. Необходимо знание гайдов и правил всех платформ, понимание того, как заказчик видит продукт и еще куча подводных камней.

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

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

Вывод

Если вы заказчик — идите к профессионалам, расскажите что и для чего вы хотите, как это видите, или просто приходите и говорите — «Хочу!». У нас в компании все сделают за заказчика, главное — не замыкаться и вести диалог.

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

Добра вам и идеального мира!