Smoke-тестирование

Согласно определению ISTQB Smoke-тестирование – это набор тестов, который охватывает основные функции компонента или системы, чтобы определить, правильно ли они работают, до начала запланированного тестирования.

Иными словами – это минимальный набор тестов, прохождение которых показывает, что продукт готов к дальнейшему тестированию. Smoke-тестирование можно также назвать «Проверкой сборки», так как с помощью Smoke-тестов мы проверяем работоспособность и стабильность сборки.

Преимущества Smoke-тестирования

У дымового тестирования много достоинств. Из самых важных:

  • Простота выполнения тестирования
  • Обнаружение дефектов на ранних этапах
  • Повышение качества системы
  • Экономия времени и ресурсов при тестировании
  • Минимизация рисков интеграции

Различие между Smoke, Sanity и Регрессионным тестированием.

  1. Smoke проверяет рабочее состояние новой сборки. Sanity-тестирование проверяет изменения, которые были сделаны в текущей сборке. Регресс проводится для проверки всего функционала, который был затронут в ходе изменения в текущей сборке.
  2. Дымовое тестирование можно выполнить на любой сборке. Sanity и Регресс выполняются только на стабильных сборках.
  3. Smoke-тестирование может выполняться как разработчиками, так и тестировщиками. Sanity и Регресс выполняются только тестировщиками
  4. Смоук-тестирование обязательно проводится для каждой новой сборки. Sanity-тестирование осуществляется, только если нет времени делать более глубокое регрессионное тестирование. Регрессионное тестирование выполняется всегда, когда нет ограничения во времени.

Как выполняется смоук-тестирование

Smoke-тестирование выполняется при каждой новой сборке. Для этого определяется минимальный набор тест-кейсов для критически важного функционала. На этапе написания тест-кейсов определяют Priority и Severity кейса. В Smoke-прогон входят кейсы с Priority High и Severity Critical, как правило, это основные пользовательские сценарии, набор кейсов для проверок интеграционных модулей. К примеру, у нас в системе используются сторонние модули для скачивания документов, отображения карт, отправки писем, регистрации через интеграционную систему – эти кейсы добавлены в Smoke-прогон.
С помощью них проверяется их рабочее состояние и дается гарантия, что все критически важные функции работают правильно. Задача – проверить, подключен ли модуль, выполняет ли он свою основную функцию. К примеру, при проверке модуля скачивания документов нужно убедиться, что документ скачивается, а что конкретно в нем отображено – это проверка в рамках регресса. Исходя из Smoke мы поняли, что модуль в общей сборке корректен и подключен к системе.

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

Как правило Smoke-тестирование выполняется вручную, но если приложение обновляется часто и есть повторяющиеся от сборки к сборке текст-кейсы, то их можно автоматизировать для экономии времени и ресурсов.

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

Если же обнаружены проблемы, то сборка отклоняется и передается обратно разработчикам для исправления. После внесения исправления тестировщик снова должен провести смоук-тестирование.

Все результаты Smoke-прогона тестировщики фиксируют в системе управления. На основании этой информации формируются диаграммы Smoke-прогона.

Пример Smoke-тестирования

Например, в тестируемом приложении есть следующие основные пользовательские сценарии:

  1. Вход в систему
  2. Регистрация пользователя
  3. Личная страница пользователя
  4. Редактирование личных данных

Для такого приложения тестировщик в ходе Smoke-тестирования должен проверить все основные пользовательские сценарии. Например:

  1. Пользователь смог войти с действительными учетными данными.
  2. Пользователь не смог войти c недействительными учетными данными.
  3. Успешное создание нового пользователя при заполнении формы регистрации валидными данными.
  4. Просмотр страницы пользователя после входа в систему.
  5. Пользователь смог отредактировать Имя/email

Заключение

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

Заказать тестирование
Правила обработки персональных данных

1. Персональные данные Посетителя обрабатываются в соответствии с ФЗ «О персональных данных» № 152-ФЗ.

2. При отправке формы обратной связи Посетитель предоставляет следующую информацию: имя, контактный номер телефона, адрес электронной почты.

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

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

5. Владелец сайта вправе использовать технологию «cookies». «Cookies» не содержат конфиденциальную информацию. Посетитель настоящим дает согласие на сбор, анализ и использование cookies, в том числе третьими лицами для целей формирования статистики и оптимизации рекламных сообщений.

6.Владелец сайта получает информацию об ip-адресе Посетителя. Данная информация не используется для установления личности посетителя.

7.Владелец сайта вправе осуществлять записи телефонных разговоров с Покупателем. При этом Владелец сайта обязуется: предотвращать попытки несанкционированного доступа к информации, полученной в ходе телефонных переговоров, и/или передачу ее третьим лицам, не имеющим непосредственного отношения к взаимодействию между Владельцем сайта и Посетителем, в соответствии с п. 4 ст. 16 Федерального закона «Об информации, информационных технологиях и о защите информации».

Письмо отправлено

Наш менеджер свяжется с вами в ближайшее время