Швейцарский нож тестировщика: разбираем главные инструменты

База для успешного тестирования — документация. Она помогает систематизировать работу тестировщика и не упустить критичные ошибки в продукте. Вот что обычно входит в документацию:

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

Документация нужна не только тестировщикам, но и остальной команде. Чтобы разработчик или системный аналитик могли легко получить к ней доступ, её нужно где-то хранить. Если команда небольшая (до 8 человек), для начала подойдёт баг-трекер — система, в которой для каждой ошибки создают карточку, назначают ответственных и сроки. Самый популярный баг-трекер — JIRA. Крупные компании и команды, которые сразу хотят строить взрослые процессы, выбирают специальные системы для управления тестированием. В них можно не только заводить карточки для багов, но и работать с кодом и метриками, строить отчёты. Примеры таких систем — Azure DevOps, Allure TestOps, Qase.

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

Чек-лист и тест-кейсы — основные инструменты тестирования на проекте. Если не уделить им внимание, можно упустить критичные ошибки. Это риск для проекта: ошибки, которые нашли уже после запуска, исправлять дороже. Студенты курса для инженеров по тестированию начинают погружаться в профессию именно с чек-листов и тест-кейсов. Затем — переходят к практике под присмотром преподавателей и опытных наставников. Тестируют веб- и мобильные приложения, базы данных и API.

Разберём пример чек-листа и тест-кейса для функции корзины в интернет-магазине.

Интернет-магазин может быть пустым или уже содержать данные вроде названия и стоимости товаров. Но чтобы протестировать оформление заказа, понадобится гораздо больше данных. Например, имя и фамилия покупателя, номер банковской карты, телефон и произвольный текст (для комментария к заказу).

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

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

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

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

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

Настройки теста в Apache JMeter

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

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

Системы для управления тестирования вроде Allure предоставляют свои дашборды. Это удобно: нужная информация уже есть в системе, и остаётся только настроить метрики. Некоторым командам нужны более гибкие инструменты, и они разрабатывают дашборды, используя платформы с открытым исходным кодом. Например, Grafana.

Пример дашборда в Allure TestOps. Панель показывает общее количество тест-кейсов, уровень автоматизации, статистику по запускам тестов

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

Когда тест проводят вручную, скриншот делает сам тестировщик. Но проверку типовых сценариев вроде авторизации часто автоматизируют, чтобы сэкономить время. Автотест — это отдельная программа, которая имитирует действия пользователя — клики, переходы на страницы, ввод текста. Тестировщик настраивает в ней тестовые сценарии, запускает и получает отчёт, из которого понимает, где в системе есть ошибки. Какую программу для автотестов выбрать — зависит от задач проекта и языка программирования, который в нём используют. Например, фреймворк TestCafe используют для проектов на JavaScript или TypeScript, a Selenium подходит сразу для нескольких языков — Java, C#, Python, Ruby, JavaScript.

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

Пример кода для создания скриншота с использованием Selenium в Python

Пример кода на JavaScript в TestCafe

Валидаторы HTML и CSS используют для проверки правильности кода веб-страниц. Они анализируют код и сообщают о нарушениях синтаксиса, несоответствии спецификациям, указывают, что именно нужно исправить. Без них проверять код пришлось бы вручную, а это очень долго.

Валидаторы работают в формате веб-сервисов. Достаточно отправить ссылку на страницу, и сервис укажет на ошибки. Один из популярных валидаторов — W3C

Эмуляторы — программы, которые помогают проверить, как сайт или приложение выглядит и работает на разных моделях смартфонов, планшетов и ноутбуков. Это помогает обнаружить и исправить проблемы совместимости перед выпуском продукта. Например, главная страница на смартфоне c Android отображается без искажений, на смартфоне с iOS уехала кнопка, а на ноутбуке появился горизонтальный скролл — признак неадаптированного сайта.

Самый популярный инструмент для тестирования приложений на Android — Android studio. XCode — аналогичный инструмент для приложений на iOS. Он запускается только на технике Apple.

В одной из последних версий Android Studio можно сравнить отображение страницы сразу на нескольких экранах. Источник: Developers-android

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

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

Инструменты для тестирования API помогают увидеть, как одна система реагирует на запросы от другой. Они отправляют запросы к API, анализируют ответы и проверяют соответствие ожидаемым результатам. Это помогает убедиться, что API может взаимодействовать с другими приложениями без ошибок. Среди популярных инструментов для тестирования API — Postman, SoapUI и Curl.