Не углубляясь в процесс тестирования, можно подумать: «Да что там тестировать? Просто смотришь, что продукт работает корректно, и всё. Какая ещё подготовка?». Может, QA-инженерам и хотелось бы, чтобы всё было так просто и подготовка к тестированию сводилась к тому, чтобы заварить себе чай и включить компьютер. А может, и не хотелось бы — эта история не об этом.

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

Зачем готовиться к тестированию продукта

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

QA-инженер берёт на себя ответственность за подачу продукта на прод. Если возникает серьёзная проблема, которая вызывает поток обращений в чат поддержки, негативные отзывы в AppStore и Google Play или недовольство заказчика, первым делом приходят к тестировщику. Поэтому в его же интересах прибегать к различным способам улучшения процесса. В частности — подготовке к тестированию.

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

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

Далее расскажем, какую работу выполняет QA-отдел в рамках подготовки к тестированию.

Изучение технической документации

Первое, что должно заинтересовать QA-инженера — техническая документация (ТД). Это файл с описанием фич, которые команда проекта планирует разработать в предстоящем спринте. Иными словами, подробное истолкование того, как и что должно функционировать и взаимодействовать в продукте.

Почему важно начинать с документации? Всё просто — это база. Без ТД далеко не уедешь, и тестировщик должен следить, чтобы всё было реализовано в соответствии с предписанными правилами «игры». Кроме того, не всегда техническая документация исчерпывающе понятна. Может потребоваться немало времени, чтобы в ней разобраться. Сделать это лучше на ранних этапах, чтобы специалист понимал, что у него будет на руках, когда таски выполнят, и насколько сложно будет проверить функциональность с точки зрения логики приложения.

При обнаружении проблем в ТД тестировщику следует поделиться своими мыслями с проджект-менеджером и заказчиком, чтобы избежать доработок, когда уже всё готово и повторное вмешательство в разработку влетит в копеечку бизнесу.

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

Проверка макетов

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

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

QA-инженеру такой подход помогает наработать насмотренность. В будущем, тестируя функциональность, он сэкономит время на поиске нужного экрана в макетах, поскольку будет ориентироваться в их наполнении.

Составление чек-листов и тест-кейсов

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

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

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

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

Настройка тестовой среды и подбор девайсов

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

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

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

Что входит в тестовую среду? Всё, что так или иначе связано с работой разрабатываемого продукта, например, настройка сети и программного обеспечения, снифферы, системы логирования. Все эти составляющие позволяют провести качественное тестирование.

Рассмотрим второй пункт — подбор девайсов. QA-инженер должен определить минимальный набор устройств, на которых нужно проверить работу продукта. В этом помогают вопросы:

• Какая операционная система (ОС) должна быть установлена на устройстве? Какая версия ОС?

• На каком разрешении экрана нужно проверить продукт?

• Нужно ли учитывать особенности и возможности самого устройства для тестирования конкретного продукта?

• Какая модель наиболее актуальна/не актуальна для пользователей, которые используют наш продукт?

Покрытие девайсов жизненно необходимо, так как одна незначительная мелочь может сильно повлиять на то, как продукт поведёт себя на конкретном устройстве. Например, мобильное приложение может по-разному работать на разных версиях ОС: на Android 9 будет крашиться или не открываться вовсе, а на более свежих версиях функционировать корректно. Пользователей со старыми версиями ОС на девайсах не так много, но про них не стоит забывать. Другой пример: на устройствах с нестандартным разрешением экрана, допустим, iPhone 16 Pro Max, может поехать вёрстка. Момент некритичный, но довольно неприятно скачать мобильное приложение и, запустив его, увидеть «кашу».

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

Вуаля — можно приступать к тестированию!

Мы добрались до кульминации и наконец-то можем перейти к тестированию продукта — финальному пазлу перед подачей продукта на прод непосредственно «в руки» пользователю.

Подытожим и выделим плюсы подготовительной работы:

1. Тестировщик погружен в проект, знает каждую фичу и строчку в ТД.

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

3. Бизнес не тратит время, деньги и нервы на переделку уже реализованной функциональности.

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