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

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

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, и стресс-тесты, и исследовательское и много чего еще.

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

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

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

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

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

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

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

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

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

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, чтобы конечный продукт был без багов? Собственно все, что описано выше, а иногда — прыгнуть выше своей головы.

Вывод

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

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

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