для чего используются smoke тесты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Источник

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

Смоук-тестирование — первый этап исследований программного обеспечения (ПО) после его создания или модернизации. Цель проверки — изучение работоспособности системы, корректности отклика и обработки данных. Smoke-тесты короткого цикла направлены на выявление критических дефектов, которые в дальнейшем могут спровоцировать архитектурные ошибки и серьезные поломки оборудования.

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

Преимущества автоматизированного Smoke Test:

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

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

Профилактика архитектурных ошибок и поломок оборудования. Выявление багов на раннем этапе позволяет своевременно устранить неполадки и предотвратить серьезные сбои в системе.

Подготовка ПО к интеграции. Для повышения функциональности в систему регулярно внедряются модули. Дымовое тестирование — это комплекс мер, направленный на минимизацию рисков при установке новых приложений.

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

Этапы смок-тестирования

Запустив первичную проверку ПО после его создания или модернизации, мы сразу поймем, корректно ли собраны модули и нет ли багов. Как только ошибки будут найдены, программу сразу же отправят на доработку без прохождения сложного цикла исследований. Такой подход позволяет значительно сэкономить время.

Для чего используются Smoke-тесты:

определение готовности ПО к запуску;

анализ стабильности веб-продукта;

соответствие функционала бизнес-процессам.

Типичными примерами смоук-тестирования служит проверка отклика системы при входе по логину с валидными данными, работоспособности кликов по кнопкам, доступности меню и других очевидных функций.

Дымовое тестирование включает в себя следующие этапы:

изучение функционала программного обеспечения;

анализ возможных рисков;

составление сценариев, определение количества проверок и времени их проведения;

разработка тест-кейсов для исследования приоритетных элементов системы;

подготовка отчета о неполадках и его рассылка компетентным сотрудникам компании.

Компания IBS AppLine не только протестирует ПО, но и предложит перечень мер, направленных на устранение ошибок.

Источник

Для чего используются smoke тесты

QA & Software Testing | Тестирование ПО запись закреплена

Дымовое тестирование (smoke test, intake test, build verification test)

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

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

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

Аналогами дымового тестирования являются Build Verification Testing и Acceptance Testing, выполняемые на функциональном уровне командой тестирования, по результатам которых делается вывод о том, принимается или нет установленная версия программного обеспечения в тестирование, эксплуатацию или на поставку заказчику.

Примеры:
1. Ошибки инсталляции: если программный продукт не устанавливается, его тестирование, скорее всего, окажется невозможным.
2. Ошибки при соединении с базой данных, актуально для архитектуры клиент-сервер.

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

Источник

QA evolution

Smoke testing

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

Пример smoke testing:

Если к примеру брать проект DI Tool STAR, то данный тип тестирования будет включать в себя проверку следующих функциональностей:
Login form (логин с валидными данными)
Log out form (клик по кнопке)
Property selection (проверка что функциональность есть и она работает)
Property Lists (что они есть, без сохранения/удаления)
Proceed to STAR
Menu (клик)
Views switching
Drawer (переключение табов, переключение кнопок внутри табов)
Export (срабатывание кнопки)
Header property selector
Favorites (проверка что функциональность есть и она работает)

Нужно определить какие задачи нужно достичь благодаря нашему приложению, какие очевидные шаги для достижения поставленной задачи, какие важные требования мы должны соблюдать и в какой последовательности.
Для этого создаем набор тестов. Набор тестов — это сгруппированная совокупность тестовых случаев, связанная определенным образом (к примеру, по функциональности).
Smoke-тесты созданы для того, чтобы проверить основную функциональность и должны быть неотъемлимой частью процесса тестирования. Они могут включать что-то простое, вроде “Могу ли я зарегистрироваться?”. Smoke-тестирование предполагает ответы ДА/НЕТ и все тест-кейсы должны быть пройдены с положительным результатом.
Smoke test должны быть быстрыми и легковесными, для того, чтобы их можно было запускать часто. В зависимости от специфика проекта, smoke test можно пройти как за несколько минут, так и за несколько часов.

Стоит понимать, что данный тип тестирования является видом тестирования продукта по глубине, а не просто видом тестовых испытаний. Как говорилось выше, данный тип тестирования определяет, пригоден ли продукт для дальнейшего, более полного тестирования. В случае, если он не проходит smoke testing — продукт необходимо отправить на доработку.
Обязательно необходимо записывать результаты прохождения теста. Это необходимо для того, чтобы сохранить записи того, что работает, а что нет. Можно разделить результаты на пройдено и провалено.
Пройдено: все отлично работает.
Провалено: не работает.

Источник

Дымовое и санитарное тестирование: понятия и характерные отличия

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

Дымовое тестирование (англ. smoke testing)

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

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

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

Дымовые тесты очень важны, так как позволяют не проводить сложные проверки уже на стадии официального релиза, дабы не выпустить потребителям некачественное ПО.

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

Ключевые преимущества дымовых тестов

Санитарное тестирование (англ. sanity testing)

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

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

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

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

Если исправленные баги и редакции кода работают неверно, тогда тестировщик не имеет права принимать сборку на тест. Отметим, что любые дефекты, найденные на такой ранней стадии, смогут сэкономить массу времени на процессе проверки недоработанной сборки.

Ключевые особенности санитарного тестирования

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

Недостатки

Сравнение дымового и санитарного тестирования

Наглядные примеры использования данных тестов

Детально рассмотрим реальные примеры проведения подобных видов проверок на основе настоящих тестовых случаев.

Пример дымового тестирования

Допустим, в проверяемом ПО есть 5 модулей, а именно:

То есть, внутри данных модулей QA проводит тестирование, проверяя основную функциональность этих модулей, а точнее:

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

Снова представим, что есть 5 модулей:

При тестировании был найден дефект на странице авторизации. К примеру, поле для ввода пароля воспринимает комбинацию исключительно из 6 символов, что категорически не соответствует ТЗ, где указанно, что пароль может быть от 4 символов.

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

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

Данные тесты проводятся только тогда, когда сборка ПО успешно прошла дымовые проверки и валидацию для последующих испытаний.

Источник