QA-инженеры в OrbitSoft проверяют каждый продукт в несколько этапов: smoke-тестирование → функциональное → регрессионное → приемочное тестирование. Благодаря услугам QA-инженеров заказчик может убедиться, что его программа, сайт или приложение работает именно так, как задумывалось.
В статье подробно рассказываем о процессе работы и о том, почему выгодно нанимать QA-инженеров на аутсорс.
Этап 1: анализ требований и составление документации
Услуги QA-тестировщиков нужны после того, как заканчивается разработка продукта. Прежде чем начать работать, QA-инженеры по тестированию составляют документацию: тестовый план, чек-листы и тест-кейсы.
Тестовый план — документ с описанием тестируемых функций, стратегий, сроков начала и окончания тестирования.
Чек-лист — это список проверок для тестирования продукта.
Тест-кейс — это описание задачи из чек-листа с ожидаемым результатом и набором предварительных условий и входных значений.
Тестировщики пишут тест-план на основе технического задания, которое составили разработчики. Например, на основе технического задания для формы оплаты на сайте.
Это пример чек-листа одного из проектов: описание функций и статус — работает или нет
Это пример тест-кейса: описание шагов для проверки работоспособности каждой функции
Этап 2: тестирование smoke-test
Чтобы найти явные ошибки, мы проводим тестирование по модели черного ящика. Еще этот процесс называют smoke-тестированием. Основная цель — проверить стабильность системы в целом.
Например, проект не сможет зарабатывать деньги, если система не умеет обрабатывать платежи. Чтобы проверить, что все работает, тестировщики заходят на страницу с платежами и проверяют, выводит их система или нет.
Если этот этап пройден успешно, тестировщик двигается дальше — к функциональным тестам. Если находит ошибку — создает задачу для разработчиков на доработку.
Скриншот программы Orbit Ad Server: на странице Manage Bank Payments у администратора должна быть возможность просмотреть все произведенные через систему банковские платежи
Этап 3: функциональное тестирование системы
На этом этапе проверяем, как функции соответствуют техническому заданию: смотрим на функциональные возможности, доступность, удобство использования, пользовательский интерфейс. Основная цель — проверка логики работы каждой функции на разных наборах данных и при различных условиях. Результатом функционального тестирования будет описание всех несоответствий и ошибок.
Если результат в процессе тестирования отличается от желаемого и причина ошибки неочевидна, инженеры формируют SQL-запрос в базу данных или обращаются за дополнительной информацией к лог-файлам проверяемой системы
Этап 4: регрессионное тестирование
После того как тестировщики находят и описывают несоответствия, проводится регрессионное тестирование. Иногда функциональное и регрессионные тестирование проводятся одновременно.
Регрессионное тестирование делится на две части:
- проверка исправлений ошибок, обнаруженных на предыдущем этапе,
- перепроверка всех функций.
Это необходимо, так как после исправления багов нет гарантии того, что случайно не сломался компонент, который проверяли ранее.
Например, разработчики исправили баг в отображении календаря — даты привели к единому формату. Это исправление могло повлиять на работу других компонентов. Тестировщики заходят в панель администратора и проверяют функции: создаются ли отчеты с датами в нужном формате, все ли виды отчетов доступны.
Если функция работает с ошибкой, тестировщики создают задания для разработчиков на исправление бага. После исправления будет выполнена повторная проверка. Если все будет работать без багов, доработки не понадобятся. Перейдем к финальному этапу тестирования.
Так выглядит панель администратора после исправления багов. Тестировщики нажимают на каждое поле и проверяют, что отчеты доступны, даты отображаются в корректном формате
Получите консультацию эксперта бесплатно
-
Разберём задачи вашего проекта
-
Предложим индивидуальное решение
-
Определим сроки и бюджет
Выберите специалиста
Этап 5: приемочное тестирование
Приемочное тестирование — это проверка основных функций, финальное тестирование перед релизом. Оно проводится для того, чтобы убедиться, насколько сценарий соответствует задаче, которую поставил заказчик. Например, открывается ли сайт на разных устройствах, может ли пользователь отправить контакты через форму, воспроизводится ли видео, открываются ли баннеры.
Когда разработка завершена и все тесты пройдены успешно, по желанию заказчика тестировщики, QA-инженеры проводят проверку на оборудовании заказчика.
В OrbitSoft большой набор устройств разных производителей и годов выпуска. Например, в Азии популярны модели телефонов, которые уже вышли из производства, поэтому для тестирования азиатских проектов в офисе хранятся такие гаджеты
Сравнение видов тестирования
Тестирование Smoke-test. Основная цель — проверить стабильность системы в целом, чтобы можно было приступать к дальнейшей разработке и более детальной проверке функций.
Тестировщики смотрят на пользовательские сценарии, а не на функциональные требования.
Функциональное тестирование. Когда проверены общие сценарии, нужно подтвердить, что система соответствует функциональным требованиям.
Тестировщики проверяют логику реализованных функций: доступность, удобство использования, пользовательский интерфейс. Важно, чтобы все соответствовало техническому заданию.
Не проводят тестирование производительности (нагрузочное, стрессовое тестирование, тестирование стабильности), тестирование установки, безопасности, конфигурационное тестирование.
Регрессионное тестирование. После функционального тестирования нужно проверить, что система не поломалась и работает нормально.
Тестировщики проверяют корректность исправлений и доработок всех недочетов, которые были обнаружены на предыдущем этапе. Пересматриваются все функции: не повлияли ли новые исправления на уже протестированные функции системы.
Во время регрессионного тестирования не проверяют функции, которые на предыдущем шаге работали, если ни одно из исправлений разработчиков не могло повлиять на состояние и логику работы этих функций.
Приемочное тестирование. Финальное тестирование перед сдачей проекта заказчику. Задача: убедиться, что разработчики реализовали все так, как просил заказчик.
Тестировщики проверяют пользовательские сценарии, но не рассматривают каждую функцию отдельно.
Примеры из проектов OrbitSoft
Заказчик | Проект | Какие тесты проводили |
Европейский развлекательный видеосервис | Добавить новую функцию «слайдер объявлений» в систему управления интернет-рекламой Orbit Ad Server | Со стороны рекламодателя тестировали: форматы внутреннего контента. Со стороны паблишера: настройки рекламы, виды отображения объявлений. Со стороны администратора, рекламодателя и паблишера проверяли, как работает система денежных взаиморасчетов, настройка отчетов. Со стороны системы: создание и показ объявлений, модерация, загрузка видео любых форматов, проставление ссылок на подтягивание видео из стороннего сервиса, корректность работы системы управления интернет-рекламой при изменении настроек и добавлении новых функций, доступность сервиса — все ОС, браузеры, VPN, в том числе при высокой нагрузке (трафик) |
Рекламное агентство «Плеймедиа» | Изменить функции сайта — поменять сценарий показа рекламы на сайте: чтобы рекламное объявление было видно не сразу, а в момент пролистывания страницы до нужного контента | Проверили сценарии отображения всех типов рекламных объявлений в соответствии с техническим заданием в разных частях веб-страницы. Через консоль браузера проверили работу скрипта, который определяет, в какой момент происходит загрузка рекламного объявления |
Технический блок
SQL-запросы к базе данных
Поиск и чтение логов через веб-интерфейс Kibana
Логирование: сбор логов — Logstash, обработка логов — Elasticsearch
Развертывание тестовых стендов:
Веб-серверы: nginx, Apache Kafka, Apache ZooKeeper, Apache Cassanda
Сервер БД: MySQL, PostgreSQL, MariaDB
Среда для запуска (компиляции): Visual Studio
Языки программирования: C#, Python, Ruby
Telegram
WhatsApp
+7 499 321-59-32
contact@orbitsoft.com