Smoke tests что это
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 Tests? Это разработка минимального набора сценариев, с помощью которых тестируются базовые функции системы после каждой сборки. Другими словами, дымовое тестирование определяет, корректно ли был собран и установлен цифровой продукт. Если не сделать первичную проверку, то при наличии ошибок дальнейшие тесты будут лишней тратой времени. Если в ПО обнаружен дефект, оно сразу направляется на доработку, не проходя весь сложный цикл исследований.
Дымовые тесты исследуют стабильность системы. С помощью проверки можно определить, запускается ли программа, есть ли обратная связь с пользователем, открывается ли правильно интерфейс, выполняются ли основные функции системы.
Примером Smoke-тестов служат следующие сценарии проверки функциональности:
Дымовому тестированию можно подвергать как модернизированные продукты, так и только что выпущенные программы, которые ранее нигде не использовались. Приемочные испытания проводятся с высокой интенсивностью, поэтому проще и дешевле заказать их автоматизацию.
Достоинства дымового тестирования
Дымовая тесты конструируются таким образом, чтобы покрыть самые приоритетные функции системы. К преимуществам относятся:
Компания IBS AppLine реализует комплекс мер, направленных на проверку соответствия ПО требованиям заказчика и бизнес-задачам. Работа осуществляется в несколько этапов:
Дымовое тестирование значительно улучшает качество приложения. Оно направлено на проверку корректности переноса баз данных со старой версии на новую. Smoke-тесты контролируют корректность взаимодействия систем между собой.
IBS AppLine реализует масштабные проекты по улучшению качества программных продуктов. Наши специалисты обеспечивают максимальное тестовое покрытие нужных сегментов ПО и за короткое время проводят наиболее критичные проверки.
Smoke tests что это
Что пишут в блогах
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Где: Кострома / онлайн
2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Оригинальная публикация: http://habr.com/post/358142/
Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта
О чём это всё
Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.
В этой статье я хотел бы внести ясность и объяснить разницу между этими видами тестирования и попробовать разобраться, провести границы (хоть и условные) где заканчивается один вид тестирования, и начинается другой.
Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?
Строго говоря, вы всё равно сможете проводить тестирование, даже при том что не сможете точно сказать, в чём же разница. Можно даже не задумываться о разграничении, каким именно видом тестирования вы сейчас заняты. Но всё же, чтобы расти над собой в профессиональном смысле, нужно знать что вы делаете, зачем, и насколько правильно вы это делаете.
Ликбез
Ниже приведены краткие определения видов тестирования, которые мы сегодня сравниваем:
Оба эти вида тестирования нацелены на то, чтобы избежать потерь времени и усилий, чтобы быстрее определить недостатки ПО и их критичность, а так же то, заслуживает ли оно перехода в фазу более углублённого и тщательного тестирования или же нет.
Для лучшего понимания ниже представлена сравнительная таблица этих понятий и области применения:
| Дымовые (Smoke) | Санити (Sanity) | Регрессионные (Regression) | Ре-тест (Re-test) |
|---|---|---|---|
| Исполняются с целью проверить что критически важные функциональные части AUT работают как положено | Нацелено на установление факта того, что определённые части AUT всё так же работают как положено после минорных изменений или исправлений багов | Подтверждают, что свежие изменения в коде или приложении в целом не оказали негативного влияния на уже существующую функциональность/набор функций | Перепроверяет и подтверждает факт того, что ранее заваленные тест-кейсы проходят после того, как дефекты исправлены |
| Цель — проверить «стабильность» системы в целом, чтобы дать зелёный свет проведению более тщательного тестирования | Целью является проверить общее состояние системы в деталях, чтобы приступить к более тщательному тестированию | Цель — убедиться что свежие изменения в коде не оказали побочных эффектов на устоявшуюся работающую функциональность | Ре-тест проверяет что дефект исправлен |
| Перепроверка дефектов не является целью Smoke | Перепроверка дефектов не является целью Sanity | Перепроверка дефектов не является целью Regression | Факт того что дефект исправлен подтверждает Re-Test |
| Дымовое тестирование выполняется перед регрессионным | Санитарное тестирование выполняется перед регрессионным и после smoke-тестов | Проводится на основании требований проекта и доступности ресурсов (закрывается автотестами), «регресс» может проводиться в параллели с ре-тестами | — Ре-тест выполняется перед sanity-тестированием — Так же, приоритет ре-теста выше регрессионных проверок, поэтому должно выполняться перед ними |
| Может выполняться автоматизированно или вручную | Чаще выполняется вручную | Лучший повод для автоматизации данного вида тестирования, т.к. ручное может быть крайне затратным по ресурсам или времени | Не поддаётся автоматизации |
| Является подмножеством регрессионного тестирования | Подмножество приёмочного тестирования | Выполняется при любой модификации или изменениях в уже существующем проекте | Ре-тест проводится на исправленной сборке с использованием тех же данных, на том же окружении, но с различным набором входных данных |
| Тест-кейсы часть регрессионных тест-кейсов, но покрывающие крайне критичную функциональность | Санитарное может выполняться без тест-кейсов, но знание тестируемой системы обязательно | Тест-кейсы регрессионного тестирования могут быть получены из функциональных требований или спецификаций, пользовательских мануалов, и проводятся вне зависимости от того, что исправили разработчики | Используется тот же самый тест-кейс, который выявил дефект |
Ну а по существу?
Приведу пример разграничения понятий на моём текущем проекте.
Пример: у нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:
Тогда можно сделать ряд утверждений о том, какие типы тестов нужно использовать в какой момент времени:
При этом, если это api принимает так же post-запросы, то очевидно что в другой набор тестов sanity нужно включить именно эти запросы. По аналогии с UI мы будем проверять все страницы приложения.
Подведём итог
Надеюсь, что после чтения данной статьи, у вас появится ясность в определении какой вид тестирования вы используете на каком этапе, и в чём разница между этими видами тестирования. Как и было упомянуто вначале, граница между этими понятиями весьма условная и остаётся на ваше усмотрение в рамках проекта.
В чём разница Smoke, Sanity, Regression, Re-test и как их различать?
Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта
О чём это всё
Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.
В этой статье я хотел бы внести ясность и объяснить разницу между этими видами тестирования и попробовать разобраться, провести границы (хоть и условные) где заканчивается один вид тестирования, и начинается другой.
Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?
Строго говоря, вы всё равно сможете проводить тестирование, даже при том что не сможете точно сказать, в чём же разница. Можно даже не задумываться о разграничении, каким именно видом тестирования вы сейчас заняты. Но всё же, чтобы расти над собой в профессиональном смысле, нужно знать что вы делаете, зачем, и насколько правильно вы это делаете.
Ликбез
Ниже приведены краткие определения видов тестирования, которые мы сегодня сравниваем:
Ну а по существу?
Приведу пример разграничения понятий на моём текущем проекте.
Пример: у нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:
Подведём итог
Надеюсь, что после чтения данной статьи, у вас появится ясность в определении какой вид тестирования вы используете на каком этапе, и в чём разница между этими видами тестирования. Как и было упомянуто вначале, граница между этими понятиями весьма условная и остаётся на ваше усмотрение в рамках проекта.
UPD:
Часто «тестирование согласованности» или «тестированием на вменяемость», называют термином «санитарное тестирование». Думаю что это пошло из-за фонетических свойств английского слова sanity, схожего по звучанию с чем-то «санитарным». Гугл транслейт вносит ясность. В интернете встречаются оба варианта. Относительно данной статьи прошу считать «санитарное» тестирование как «тестирование на согласованность».
Дымовое и санитарное тестирование: понятия и характерные отличия
Обычно люди запутываются в значениях дымового и санитарного тестирования. Прежде всего, эти два понятия очень разные, да и QA выполняет их на разных этапах цикла тестирования.
Дымовое тестирование (англ. smoke testing)
Дымовое тестирование– это особый вид проверки программного обеспечения, направленный на тщательный анализ работоспособности разрабатываемого веб-продукта, а именно наиболее важных и критических моментов. Итоги подобных проверок применяются для того, чтобы понять, можно ли характеризовать созданное ПО как максимально стабильную сборку для последующего тестирования.
Выполнение дымового тестирования проводиться тогда, когда QA-отдел внутри компаний по обеспечению качества получает в работу новую версию ПО, изначально считая ее не до конца доработанной и исправной. При подобной проверке крайне важно убедиться в том, что все самые важные параметры тестируемого продукта функционируют корректно и согласно заявленным ожиданиям.
Философия подобного вида тестирования основывается на том, что тестировщики должны как можно ранее найти источник и причины возникновения багов и отклонить проверяемую версию на последующую доработку программистам.
Дымовые тесты очень важны, так как позволяют не проводить сложные проверки уже на стадии официального релиза, дабы не выпустить потребителям некачественное ПО.
Базовая задача такого рода тестов заключается в быстрой проверке работоспособности и стабильности программного обеспечения в целом, без надобности проведения тщательных проверок в будущем.
Ключевые преимущества дымовых тестов
Санитарное тестирование (англ. sanity testing)
Санитарное тестирование – очень специфическая проверка работоспособности отдельных функциональных элементов, систем, веб-архитектур и расчетов. Она выполняется с единственной целью – дать 100% понятие того, что создаваемая система работает именно так, как того и требовалось.
Подобный тип тестирования нередко выполняется до старта полного цикла проведения регрессионных проверок, но только после окончания дымового тестирования.
Традиционно, санитарные проверки выполняются тогда, когда исправлен незначительный дефект внутри системы или ранее выполнялись работы по частичном редактировании логики работы ПО.
Как только изменения были внесены в код, новая сборка программного обеспечения передается на проверку в отдел тестирования. После установки сборки QA-специалисты могут выполнять эффективную проверку отредактированной функциональности вместо полной регрессии программного обеспечения, которое занимает существенно больше времени.
Если исправленные баги и редакции кода работают неверно, тогда тестировщик не имеет права принимать сборку на тест. Отметим, что любые дефекты, найденные на такой ранней стадии, смогут сэкономить массу времени на процессе проверки недоработанной сборки.
Ключевые особенности санитарного тестирования
Преимущества санитарного тестирования
Недостатки
Сравнение дымового и санитарного тестирования
| Дымовое тестирование | Санитарное тестирование |
|---|---|
| Выполняется исключительно на начальных стадиях разработки ПО еще до начала проведения регрессионных проверок | Осуществляется на сборках, которые успешно прошли дымовое тестирование и им еще предстоит полный цикл регрессионных проверок |
| Сборка может быть как стабильной, так и нестабильной | Сборка отличается максимально стабильной работой |
| Мотивы подобного тестирования основываются на надобности знакомства с новыми версиями ПО | Базовая цель – тестирование рациональности работы внедренных конфигураций для последующего тщательного тестирования |
| Критические ошибки при дымовом тестировании моментально приводят к отказу от использования этой сборки ПО | Найденные ошибки позволяют переместить сборку в список отклоненных, с которыми еще предстоит иметь дело |
| Проводиться в равной степени что QA-специалистами, что отделом разработки | Традиционно работа тестировщика |
| Состоит из определенной документации и работы по заранее созданным сценариям | Четко выраженного акцента на работе по сценариям нет |
| Выполняется как вручную, так и с помощью запрограммированных автотестов | Проводится исключительно вручную |
Наглядные примеры использования данных тестов
Детально рассмотрим реальные примеры проведения подобных видов проверок на основе настоящих тестовых случаев.
Пример дымового тестирования
Допустим, в проверяемом ПО есть 5 модулей, а именно:
То есть, внутри данных модулей QA проводит тестирование, проверяя основную функциональность этих модулей, а точнее:
Пример санитарного тестирования
Снова представим, что есть 5 модулей:
При тестировании был найден дефект на странице авторизации. К примеру, поле для ввода пароля воспринимает комбинацию исключительно из 6 символов, что категорически не соответствует ТЗ, где указанно, что пароль может быть от 4 символов.
Тестер сообщил разработчику о найденном дефекте, чтобы он исправил его. Ошибка была исправлена, и модуль возвращается на тест QA-специалистам, которые также должны проверить работу и остальных 4 модулей. Они должны убедится в том, что тестирование исправленного бага не повлияло на корректную функциональность остальных систем и логик.
Но важно понимать, что при таком подходе тестируется только экстремальная функциональность модулей, нет никакого углубления в проверку деталей из-за отсутствия времени. Это и есть процедура санитарного тестирования.
Данные тесты проводятся только тогда, когда сборка ПО успешно прошла дымовые проверки и валидацию для последующих испытаний.