Smoke testing это минимальный набор тестов на явные ошибки

• Почему так странно называется
• Когда применяется
• Зачем нужно в жизненном цикле
• Может быть и ручным, и автоматизированным
• Примеры дымового тестирования
• Контрольные вопросы, которые надо знать на собеседовании

Когда говорят о тестировании в ИТ, подразумевают процесс поиска ошибок, длящийся недели, а то и месяцы. Существует быстрое тестирование — это так называемое smoke-тестирование (smoke testing, «дымовое тестирование»). Коротко: это предварительное тестирование самых важных функций.

Происхождение. Почему дымовое тестирование так называется

Есть несколько версий:

• Из-за того, что проверка начинается «пока аппарат еще дымится», то есть устройство только что собрано (то есть, только что закончена пайка).
• Терминология водопроводчиков. Водопроводчики проверяли герметичность труб, запуская туда дым. Если в трубе была дыра, ее находили по струйке дыма.
• Наиболее правдоподобная версия: термин инженеров-электротехников. Когда на электрическую цепь впервые подавалось питание, она могла дымиться если пайка была небрежной, или если в устройстве были дефекты.

Когда применяется

Предназначение дымового тестирования: проверка важнейших функций приложения. Простой и быстрый метод проверки приложения на ранней стадии разработки. 

В терминологии QA, это предварительное тестирование приложения после билда, но перед релизом, отвечающее на вопрос работает ли приложение в целом?

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

Зачем нужно в жизненном цикле

Если смотреть интегрально, с точки зрения QA и CI-CD-пайплайна, то смок-тестирование — это о том как проверить, что остальные виды тестирования уже валидные, то есть можно идти дальше. Ведь если билд падает при установке, или если половина страниц сайта не грузится, то нет смысла продолжать тестирование, пока такие крупные дефекты не уберут.

Может быть и ручным, и автоматизированным

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

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

Может быть и гибридное тестирование: сочетание ручного и автоматизированного.

Конкретные этапы смок-тестирования зависят от приложения — далее.

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

Итак, цель «дымного тестирования» — убедиться, что приложение уже рабочее, функциональности уже достаточно, чтобы идти дальше, к следующим этапам тестирования/разработки. Теперь поговорим о том, на что смотрят во время smoke-testing «стандартного приложения»:

• Какие главные функции пользователь использует — работают ли они?
• Какие «поддерживающие» функции он использует? (то есть тоже необходимые, вроде входа в свой аккаунт)
• Работает ли навигация?
• Приложение может  читать/записывать данные без проблем?

Например такие грубые дефекты не должно пропустить смок-тестирование:

Пример 1: пользователь не может вылогиниться из приложения.

Пример 2: на странице логина не срабатывает кнопка “Submit” перехода к следующей странице, несмотря на корректные логин/пароль.

***

В некоторых книгах по QA встречаются более академически правильные названия smoke-тестов: входные тесты (intake tests, термин одобряет ISTQB); тесты верификации билда (build verification tests, BVT-тесты); или тестирование сборки. 

***

Контрольные вопросы, которые нужно знать для собеседования / junior QA Interview Questions & Answers: smoke testing

Что входит в смок-тестирование?

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

Какие дефекты являются целью смок-тестирования?

Легко находимые критические и блокирующие дефекты.

Когда проводится смок-тест? На каком этапе нужно проводить смок-тестирование?

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

Зачем нужно Smoke тестирование?

Цель такого тестирования – проверить, что после очередной сборки программного продукта нет явных, грубых дефектов, «блокирующих дальнейший путь». 

Почему называется smoke testing?

Это странное название происходит из истории XX века, а именно: крайне несовершенных электрических приборов того времени. Если при включении электроприбора был виден дым (или был запах горелой проводки) – прибор еще нерабочий.

Что такое sanity-тестирование? Это не то же, что smoke-тестирование? В чем разница между дымовым тестированием и санитарным?

Смок-тестирование проверяет критически важный функционал приложения; а санитарное тестирование проверяет отдельный модуль приложения. 

(Более правильно “санитарное тестирование” называется “тестированием согласованности”, но термин “санитарное” уже прижился у российских тестировщиков).

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

Расположите известные вам типы тестов в порядке их выполнения:

QA-тесты стандартно выполняются в таком порядке: юнит-тесты, интеграционные, санити-тесты, смок-тесты, функциональные тесты.

Как связаны смок-тесты и регрессионные?

Смок-тесты с теоретической точки зрения являются подмножеством регрессионных.

Кто проводит smoke-тестирование? Разработчики или тестировщики?

По ситуации. Чаще это делают тестировщики, но лучше это получается у разработчиков )

Отлично! А нарисуете схему смок-тестирования?

• Smoke test на Jargon File (англ.)

Wikimedia Foundation
.
2010
.

Смотреть что такое «Smoke test» в других словарях:

smoke test
— noun A method of testing for leaks in drain pipes or chimneys by introducing dense smoke, often by using a smoke bomb Main Entry: smoke … Useful english dictionary

smoke test
— Test made to determine completeness of combustion … Dictionary of automotive terms


smoke test
— 1. noun a) A test for leaks involving blowing smoke into a tube or pipe. b) A preliminary test on a newly constructed piece of electronic equipment, consisting simply of the application of electrical power, to make sure that no egregious wiring… … Wiktionary

Smoke testing
— is a term used in plumbing, woodwind repair, electronics, computer software development, and the entertainment industry. It refers to the first test made after repairs or first assembly to provide some assurance that the system under test will… … Wikipedia

Smoke testing
— bzw. Rauchtest ist ein Begriff aus dem Englischen, gebräuchlich im handwerklichen Bereich (z. B. in der Klempnerei, Elektronik oder beim Bau von Holzblasinstrumenten) wie auch in der Softwareentwicklung. Es bezeichnet den ersten… … Deutsch Wikipedia

Smoke
— is the collection of airborne solid and liquid particulates and gases [ SFPE Handbook of Fire Protection Engineering] emitted when a material undergoes… … Wikipedia

Test suite
— In software development, a test suite, less commonly known as a validation suite , is a collection of test cases that are intended to be used to test a software program to show that it has some specified set of behaviours. A test suite often… … Wikipedia

Smoke bomb
— A smoke bomb is a firework designed to produce smoke upon ignition. While there are smoke generating devices that are dropped from airplanes, the term smoke bomb is used to describe the three types of devices:# A smoke ball is a hollow, cherry… … Wikipedia

После проведения необходимых изменений, таких как исправление бага/дефекта, программное обеспечение должно быть перетестировано для подтверждения того факта, что проблема была действительно решена. Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта:

— Дымовое тестирование
(Smoke Testing)

— Регрессионное тестирование
(Regression Testing)

— Тестирование сборки
(Build Verification Test)

— Санитарное тестирование или проверка согласованности/исправности
(Sanity Testing)

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

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

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

Сам по себе термин «Регрессионное тестирование», в зависимости от контекста использования может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных типа
регрессионного тестирования:

— Регрессия багов (Bug regression)
– попытка доказать, что исправленная ошибка на самом деле не исправлена.

— Регрессия старых багов (Old bugs regression)
– попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться.

— Регрессия побочного эффекта (Side effect regression)
– попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения.

Санитарное тестирование или проверка согласованности/исправности (Sanity Testing) –
это узконаправленное тестирование, достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружающей среде. Обычно выполняется вручную.

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

Тестирование сборки
(Build Verification Test) – это тестирование, направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.

Тестирование Установки (Installation Testing) –
направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения. В настоящий момент наиболее распространена установка ПО при помощи инсталляторов
(специальных программ, которые сами по себе так же требуют надлежащего тестирования). В реальных условиях инсталляторов может не быть. В этом случае придется самостоятельно выполнять установку программного обеспечения, используя документацию в виде инструкций или readme файлов, шаг за шагом описывающих все необходимые действия и проверки. В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого, зачастую, пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll–back) к предыдущей версии, в случае неудачи. Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя – это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших задач по обеспечению качества программного обеспечения.

Именно такой комплексный подход с написанием планов, пошаговой проверкой установки и отката инсталляции, полноправно можно назвать тестированием установки или Installation Testing.

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

Практика применяемая, к примеру, в Microsoft и некоторых других компаниях, занимающихся разработкой ПО, заключается в ежедневной сборке (билдовании) программы, которая дополняется дымовым тестированием. Ежедневно, после того, как каждый файл собран (сбилдован, построен), связан (слинкован), и объединен в выполнимую программу, сама программа подвергается достаточно простому набору тестов, цель которых заключается в том, чтобы увидеть, «дымит» ли программа во время работы. Эти тесты и называются дымовыми (от англ. smoke — дым). Чаще всего этот процесс достаточно хорошо автоматизирован (или должен таким быть).

ПРЕИМУЩЕСТВА.

Этот простой процесс обеспечивает несколько существенных преимуществ.

Минимизация риска при интеграции

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

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

Снижения риска низкого качества программного продукта

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

Помощь в диагностике ошибок

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

Улучшение морального духа

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

Использование ежедневного билдования и дымовых тестов

Вот несколько подробностей этого принципа.

Ежедневная сборка приложения

Фундаментальной частью ежедневной сборки является сборка той части, что была сделана последней. Джим Маккарти (Jim McCarthy) в журнале Dynamics of Software Development (Microsoft Press, 1995) назвал ежедневное билдование проекта его сердцебиением. Если сердцебиения нет — проекта нет, он мертв. Менее образно ежедневное билдование описали Майкл Касамано (Michael Cusumano) и Ричард Селби (Richard W. Selby), назвав его синхронизирующим импульсом проекта (Microsoft Secrets, The Free Press, 1995). Каждый разработчик пишет код по своему и он, код, может выходить за общепринятые на проекте рамки — это нормально, но при каждом воздействии синхронизирующего импульса код возвращается к стандарту. Настаивая на ведении разработки с использованием импульса синхронизации постоянно, Вы препятствуете выходу проекта из синхронизации полностью.

В некоторых компаниях принято собирать проект не каждый день, а раз в неделю. Эта система ошибочна, т.к. в случае «поломки» в проекте на текущей неделе, может пройти ещё пара недель до следующей удачной сборки. В таком случае компания теряет все преимущества системы ежедневной сборки проекта.

Проверка на неудачную сборку

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

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

Хорошей сборкой является та, при которой как минимум:

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

Ежедневные дымовые тесты

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

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

Дымовое тестирование должно развиваться на уровне с проектом. В начале, дымовые тесты будут проверять что-то простое, например, может ли проект выдавать сообщение «Hello, World!». С развитием системы, дымовые тесты становятся более глубокими. Время, которое тратится на первые дымовые тесты, исчисляется несколькими секундами, однако с ростом системы растет и количество необходимого для дымового тестирования времени. В конце проекта дымовое тестирование может длится на протяжении часов.

Определение группы сборки

На большинстве проектов, есть определенный сотрудник, ответственный за проверку ежедневной сборки системы и выполнение дымовых тестов. Эта работа является частью обязанностей данного сотрудника, но на больших проектах таких сотрудников может быть больше и такая работа является основной их обязанностью. Например, в группе сборки проекта Windows NT 3.0 было четыре человека (Pascal Zachary, Showstopper!
, The Free Press, 1994).

Добавляйте ревизию в сборку только если это имеет смысл

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

Введите систему штрафов за срыв выпуска очередной сборки (выпуск не рабочей сборки).

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

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

Но на некоторых проектах вводятся более серьезные штрафные санкции. Например, разработчики компании Microsoft, состоящие в проектах с высоким приоритетом (Windows NT, Windows 95, Excel), носили пейджеры и, в случае обнаружения проверки, они должны были прибыть на работу. Даже если поломка или ошибка были обнаружены в 3 утра.

Собирайте систему и «дымите» ее даже под давлением

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

Кто выигрывает от этого процесса? Некоторые разработчики протестуют против ежедневных сборок, обосновывая свои протесты непрактичностью этого занятия и его большими временными затратами. Но все сложные системы последнего времени подвергались ежедневным сборкам и прогонке дымовых тестов. К моменту своего выпуска, Microsoft Windows NT 3.0 содержала в 40 000 файлах 5,6 миллионов строк. Полная сборка занимала 19 часов и выполнялась на нескольких компьютерах. Несмотря на это, разработчики умудрялись ежедневно собирать систему. Будучи профессиональной командой, группа разработчиков NT, своим успехом во многом обязана ежедневной сборке. Те разработчики, которые работают на менее сложных проектах и, поэтому, не пользуются преимуществами процесса ежедневной сборки, должны задуматься над тем, чтоб придумать себе какие-то разумные объяснения.

Перевод разбавлен размышлениями и дополнениями автора из своего опыта

О чём это всё

Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.

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

Ликбез

Ниже приведены краткие определения видов тестирования, которые мы сегодня сравниваем:

• Дымовые тесты
  : выполняются каждый раз, когда мы получаем новый билд (версию), проекта (системы) на тестирование, при этом считая её относительно нестабильной. Нам нужно убедиться что критически важные функции AUT (Application Under Test) работают согласно ожиданиям. Идея данного вида тестирования заключается в том, чтобы выявить серьёзные проблемы как можно раньше, и отклонить этот билд (вернуть на доработку) на раннем этапе тестирования, чтобы не углубляться в долгие и сложные тесты, не затрачивая тем самым время на заведомо бракованное ПО.
• Санитарное тестирование
  : используется каждый раз, когда мы получаем относительно стабильный билд ПО, чтобы определить работоспособность в деталях. Иными словами, здесь проходит валидация того, что важные части функциональности системы работают согласно требованиям на низком уровне.

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

• Ре-тест
  : проводится в случае, если фича/функциональность уже имела дефекты, и эти дефекты были недавно исправлены
• Регрессионные тесты
  : собственно то, что занимает львиную долю времени и для чего существует автоматизация тестирования. Проводится регрессионное тестирование AUT тогда, когда нужно убедиться что новые (добавленные) функции приложения / исправленные дефекты не оказали влияния на текущую, уже существующую функциональность, работавшую (и протестированную) ранее.

Для лучшего понимания ниже представлена сравнительная таблица этих понятий и области применения:

Дымовые (Smoke)	Санити (Sanity)	Регрессионные (Regression)	Ре-тест (Re-test)
Исполняются с целью проверить что критически важные функциональные части AUT работают как положено	Нацелено на установление факта того, что определённые части AUT всё так же работают как положено после минорных изменений или исправлений багов	Подтверждают, что свежие изменения в коде или приложении в целом не оказали негативного влияния на уже существующую функциональность/набор функций	Перепроверяет и подтверждает факт того, что ранее заваленные тест-кейсы проходят после того, как дефекты исправлены
Цель — проверить «стабильность» системы в целом, чтобы дать зелёный свет проведению более тщательного тестирования	Целью является проверить общее состояние системы в деталях, чтобы приступить к более тщательному тестированию	Цель — убедиться что свежие изменения в коде не оказали побочных эффектов на устоявшуюся работающую функциональность	Ре-тест проверяет что дефект исправлен
Перепроверка дефектов не является целью Smoke	Перепроверка дефектов не является целью Sanity	Перепроверка дефектов не является целью Regression	Факт того что дефект исправлен подтверждает Re-Test
Дымовое тестирование выполняется перед регрессионным	Санитарное тестирование выполняется перед регрессионным и после smoke-тестов	Проводится на основании требований проекта и доступности ресурсов (закрывается автотестами), «регресс» может проводиться в параллели с ре-тестами	— Ре-тест выполняется перед sanity-тестированием — Так же, приоритет ре-теста выше регрессионных проверок, поэтому должно выполняться перед ними
Может выполняться автоматизированно или вручную	Чаще выполняется вручную	Лучший повод для автоматизации данного вида тестирования, т.к. ручное может быть крайне затратным по ресурсам или времени	Не поддаётся автоматизации
Является подмножеством регрессионного тестирования	Подмножество приёмочного тестирования	Выполняется при любой модификации или изменениях в уже существующем проекте	Ре-тест проводится на исправленной сборке с использованием тех же данных, на том же окружении, но с различным набором входных данных
Тест-кейсы часть регрессионных тест-кейсов, но покрывающие крайне критичную функциональность	Санитарное может выполняться без тест-кейсов, но знание тестируемой системы обязательно	Тест-кейсы регрессионного тестирования могут быть получены из функциональных требований или спецификаций, пользовательских мануалов, и проводятся вне зависимости от того, что исправили разработчики	Используется тот же самый тест-кейс, который выявил дефект

Ну а по существу?

Приведу пример разграничения понятий на моём текущем проекте.

Пример: у нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:

• Что у него есть 10 точек входа, для простоты, в нашем случае расположенных на одном IP
• Мы знаем все они принимают GET-запрос на вход, возвращая какие-либо данные в формате json.

Тогда можно сделать ряд утверждений о том, какие типы тестов нужно использовать в какой момент времени:

• Выполнив один простой GET-запрос к одной из этих точек входа, и получив ответ в формате json, мы уже убеждаемся что дымное тестирование пройдено.
  Если же одна из этих точек входа так же возвращает данные из БД, тогда как первая — нет, нужно дополнительно выполнить ещё один запрос, чтобы убедиться что приложение
  верно обрабатывает запросы к базе. И на этом «дымный» тест закончен.

  То есть мы выполнили запрос — от сервиса пришёл ответ, и он не «задымился», то есть не вернул ошибку 4хх или 5хх, и что-то невнятное, вместо json. На этом можно сказать что «дымный» тест пройден. Для проверки того, что работает так же и UI достаточно просто один раз открыть страницу в браузере.

• Санитарное тестирование в данном случае будет состоять из выполнения запроса ко всем 10 точкам входа в api, сверкой полученного json с ожидаемым, а так же наличием требуемых данных в нём.
• Регрессионные тесты будут состоять из smoke + sanity + UI выполняемые вместе в одной куче. Цель: проверить что добавление 11-ой точки входа не поломало, к примеру, восстановление пароля.
• Ре-тест в данном примере это точечная проверка что, к примеру, сломавшаяся точка входа в api в следующем билде отрабатывает как задумывалось.

При этом, если это api принимает так же post-запросы, то очевидно что в другой набор тестов sanity нужно включить именно эти запросы. По аналогии с UI мы будем проверять все страницы приложения.

Подведём итог

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

UPD
:
Часто «тестирование согласованности» или «тестированием на вменяемость», называют термином «санитарное тестирование». Думаю что это пошло из-за фонетических свойств английского слова sanity, схожего по звучанию с чем-то «санитарным». Гугл транслейт вносит ясность . В интернете встречаются оба варианта. Относительно данной статьи прошу считать «санитарное» тестирование как «тестирование на согласованность».

Спасибо за наводку

Smoke testing (встречаются названия intake test , build verification test) — тестирование, проводимое на начальном этапе (например после нового билда) и в первую очередь направленное на проверку готовности разработанного продукта к проведению более расширенного тестирования, определения общего состояния качества продукта.

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

Если к примеру брать проект 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 — продукт необходимо отправить на доработку.
Обязательно необходимо записывать результаты прохождения теста. Это необходимо для того, чтобы сохранить записи того, что работает, а что нет. Можно разделить результаты на пройдено и провалено.
Пройдено: все отлично работает.

Провалено: не работает.

Разработка смоук-теста

Дымовой тест (англ. Smoke testing или smoke test, дымовое тестирование) — в тестировании программного обеспечения означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется программистом; не проходившую этот тест программу не имеет смысла отдавать на более глубокое тестирование.

Блог

Smoke-тестирование (или дымовое тестирование) — это минимальный набор тестов, прохождение которых показывает, что продукт готов к дальнейшему тестированию. Почему этот этап так важен и как он проходит? Давайте разберёмся в этой статье.

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

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

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

Чем различаются Smoke, Sanity и Регрессионное тестирование?

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

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

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

•  К примеру, у нас в системе используются сторонние модули для скачивания документов, отображения карт, отправки писем, регистрации через интеграционную систему. Эти кейсы добавлены в Smoke-прогон. Тестировщики должны убедиться, что все критически важные функции работают правильно: подключены ли модули, выполняют ли они свою основную функцию. К примеру, при проверке модуля скачивания документов нужно убедиться, что документ скачивается, а что конкретно в нем отображено – уже задача для регресса.

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

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

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

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

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

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

Заключение

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

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

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

Как проводится дымовое тестирование

Дымовое тестирование осуществляется при выпуске каждой новой сборки. Такая проверка включает в себя несколько этапов.

Планирование. Smoke-тест планируется, как правило, в начале проекта командой quality assurance (QA) инженеров в сотрудничестве с менеджером проекта, программистами, заказчиками и пользователями. Типичное планирование выглядит следующим образом:

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

Выполнение. Это непосредственно этап самого тестирования. В ходе него проверяемая сборка подвергается испытанию в рамках предварительно разработанных тест-кейсов:

• в продукт водятся определенные на этапе планирования исходные данные;
• полученные выходные данные фиксируются для дальнейшей оценки.

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

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

Рассмотрим алгоритм smoke-тестирования на примере основных функций сайта или веб-приложения, где предусмотрена регистрация и авторизация пользователей, — например, соцсети или электронной почты. В них предусмотрены основные пользовательские функции:

• регистрация пользователя;
• авторизация в системе;
• личная страница пользователя;
• редактирование личных данных.

Для проверки этого функционала тестировщик в ходе дымового тестирования должен провести основные пользовательские сценарии:

• успешное создание аккаунта при введении валидных сведений (телефона, электронной почты, имени, фамилии и т.д.) в поля регистрационной формы;
• успешный вход с валидными учетными данными (логином и паролем, полученными или заданными при регистрации);
• неудачная авторизация с помощью недействительных учетных данных;
• просмотр страницы пользователя после авторизации;
• успешное изменение регистрационных данных (например имени или адреса email).

Что проверяется с помощью дымовых тестов

Дымовое тестирование проводится для проверки основных функций программного продукта. Соответственно, содержание конкретного теста зависит от того, для чего разработан этот продукт:

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

Дымовое тестирование может применяться как к новому, так и к модернизированному продукту.

Когда проводится smoke-тестирование

Дымовое тестирование является первым, поверхностным этапом проверки. Его цель заключается в том, чтобы избежать напрасных трат ресурсов и времени на более сложные тесты в том случае, когда продукт не выполняет основные функции. Проводить smoke-тесты имеет смысл в следующих случаях:

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

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

• Экономия времени и ресурсов. Smoke-тесты сравнительно простые и не требуют значительных затрат на свое проведение, могут осуществляться самими разработчиками или ограниченной командой QA-инженеров. В то же время они могут показать, что текущая сборка не выполняет даже основных своих задач и потому проводить более глубокое и затратное тестирование просто не имеет смысла до тех пор, пока главный функционал продукта не будет стабильно работать.
• Автоматизация. Дымовые тесты обычно стандартные и повторяющиеся для каждой сборки одного и того же продукта или различных однотипных проектов. Соответственно, для ускорения и упрощения тестирование можно автоматизировать. Однако автоматизация самого теста зачастую может быть труднее его «ручного» проведения, поэтому ее нужно осуществлять соразмерно сложности проекта.
• Стабильность сборки. В случае, когда сборки выпускаются часто, регулярное проведение smoke-тестов придает разработчику и другим задействованным в разработке продукта сторонам уверенность, что он будет работать стабильно по крайней мере в отношении основных функций. Соответственно, на каких-то этапах можно опустить затратную глубокую проверку — например, если текущий билд отличается от предыдущего незначительными изменениями.
• Обнаружение проблем на ранних этапах. Особенно это преимущество проявляется в непрерывной интеграции, когда продукт проходит быструю и частую смену итераций. Потенциально такая скорость может привести к накоплению большого количества ошибок в финальной версии. Внедрение smoke-тестов в рамках каждого цикла позволяет этого избежать.

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

• Ограниченность. Smoke-тесты покрывают только основные функции приложения. Соответственно, их проведение не гарантирует, что продукт будет работать абсолютно без ошибок, в том числе критических.
• Стереотипность. Повторяющиеся и стандартизированные smoke-тесты упрощают их проведение и автоматизацию. Однако в процессе работы приложения могут возникнуть непредвиденные новые ошибки, тестовые сценарии для которых не были заранее предусмотрены.

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