QA-инженеры в OrbitSoft проверяют каждый продукт в несколько этапов: smoke-тестирование → функциональное → регрессионное → приемочное тестирование. Благодаря тщательным проверкам заказчик получает те функции, которые ожидает. В статье подробно рассказываем о процессе работы.
Этап 1: анализ требований и составление документации
Тестирование начинается после того, как заканчивается разработка продукта. Прежде чем начать работать, тестировщики составляют документацию: тестовый план, чек-листы и тест-кейсы.
Тестовый план — документ с описанием тестируемых функций, стратегий, сроков начала и окончания тестирования.
Чек-лист — это список проверок для тестирования продукта.
Тест-кейс — это описание задачи из чек-листа с ожидаемым результатом и набором предварительных условий и входных значений.
Тестировщики пишут тест-план на основе технического задания, которое составили разработчики. Например, на основе технического задания для формы оплаты на сайте.
Это пример чек-листа одного из проектов: описание функций и статус — работает или нет
Это пример тест-кейса: описание шагов для проверки работоспособности каждой функции
Этап 2: smoke-тестирование
Чтобы найти явные ошибки, мы проводим тестирование по модели черного ящика. Еще этот процесс называют smoke-тестированием. Основная цель — проверить стабильность системы в целом.
Например, проект не сможет зарабатывать деньги, если система не умеет обрабатывать платежи. Чтобы проверить, что все работает, тестировщики заходят на страницу с платежами и проверяют, выводит их система или нет.
Если этот этап пройден успешно, тестировщик двигается дальше. Если находит ошибку — создает задачу для разработчиков на доработку.
Скриншот программы Orbit Ad Server: на странице Manage Bank Payments у администратора должна быть возможность просмотреть все произведенные через систему банковские платежи
Этап 3: функциональное тестирование
На этом этапе проверяем, как функции соответствуют техническому заданию: смотрим на функциональные возможности, доступность, удобство использования, пользовательский интерфейс. Основная цель — проверка логики работы каждой функции на разных наборах данных и при различных условиях. Результатом функционального тестирования будет описание всех несоответствий и ошибок.
Если результат в процессе тестирования отличается от желаемого и причина ошибки неочевидна, инженеры формируют SQL-запрос в базу данных или обращаются за дополнительной информацией к лог-файлам проверяемой системы
Этап 4: регрессионное тестирование
После того как тестировщики находят и описывают несоответствия, проводится регрессионное тестирование. Этот этап делится на две части: первая — проверка исправлений ошибок, обнаруженных на предыдущем этапе, вторая — перепроверка всех функций. Это нужно делать, так как после исправления багов нет гарантии того, что случайно не сломался компонент, который проверяли ранее.
Например, разработчики исправили баг в отображении календаря — даты привели к единому формату. Это исправление могло повлиять на работу. Тестировщики заходят в панель администратора и проверяют функции: создаются ли отчеты с датами в нужном формате, все ли виды отчетов доступны.
Если функция работает с ошибкой, тестировщики заводят задания для разработчиков на исправление бага. После исправления будет выполнена повторная проверка. Если все будет работать без багов, доработки не понадобятся. Перейдем к финальному этапу тестирования.
Так выглядит панель администратора после исправления багов. Тестировщики нажимают на каждое поле и проверяют, что отчеты доступны, даты отображаются в корректном формате
Этап 5: приемочное тестирование
Финальное тестирование перед релизом. Проводится для того, чтобы проверить, насколько сценарий соответствует задаче, которую поставил заказчик. Приемочное тестирование проверяет основные функции. Например, сайт открывается на разных устройствах, пользователь может отправить контакты через форму, видео воспроизводится, баннеры открываются.
Когда разработка завершена и все тесты пройдены успешно, по желанию заказчика QA-инженеры проводят тестирование на проде на оборудовании заказчика.
В OrbitSoft большой набор устройств разных производителей и годов выпуска. Например, в Азии популярны модели телефонов, которые уже вышли из производства, поэтому для тестирования азиатских проектов в офисе хранятся такие гаджеты
Сравнение видов тестирования
Smoke-тестирование. Самые первые тесты. Основная цель — проверить стабильность системы в целом, чтобы можно было приступать к дальнейшей разработке и более детальному тестированию функций.
Тестировщики проверяют пользовательские сценарии и не смотрят на нефункциональные требования.
Функциональное тестирование. Когда реализованы отдельные функции системы, нужно подтвердить, что система соответствует функциональным требованиям.
Тестировщики проверяют логику реализованных функций: доступность, удобство использования, пользовательский интерфейс, API базы данных. Важно, чтобы все соответствовало техническому заданию.
Не проводят тестирование производительности (нагрузочное, стрессовое тестирование, тестирование стабильности), тестирование установки, безопасности, конфигурационное тестирование.
Регрессионное тестирование. После функционального тестирования нужно проверить, что система не поломалась и работает нормально.
Тестировщики проверяют корректность исправлений и доработок всех недочетов, которые были обнаружены на предыдущем этапе. Пересматриваются все функции, чтобы новые исправления не повлияли на уже протестированные функции системы.
Во время регрессионного тестирования не проверяют функции, которые на предыдущем шаге работали, если ни одно из исправлений разработчиков не могло повлиять на состояние и логику работы этих функций.
Приемочное тестирование. Финальное тестирование перед сдачей проекта заказчику. Задача: убедиться, что разработчики реализовали все так, как просил заказчик.
Тестировщики проверяют пользовательские сценарии, но не рассматривают каждую функцию отдельно.