в чем разница между дымовым и санитарным тестированием
В чём разница 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 модулей. Они должны убедится в том, что тестирование исправленного бага не повлияло на корректную функциональность остальных систем и логик.
Но важно понимать, что при таком подходе тестируется только экстремальная функциональность модулей, нет никакого углубления в проверку деталей из-за отсутствия времени. Это и есть процедура санитарного тестирования.
Данные тесты проводятся только тогда, когда сборка ПО успешно прошла дымовые проверки и валидацию для последующих испытаний.
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 Testing
Понятие дымовое тестирование пошло из инженерной среды:
«При вводе в эксплуатацию нового оборудования («железа») считалось, что тестирование прошло удачно, если из установки не пошел дым.»
В области же программного обеспечения, дымовое тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.
Вывод о работоспособности основных функций делается на основании результатов поверхностного тестирования наиболее важных модулей приложения на предмет возможности выполнения требуемых задач и наличия быстронаходимых критических и блокирующих дефектов. В случае отсутствия таковых дефектов дымовое тестирование объявляется пройденным, и приложение передается для проведения полного цикла тестирования, в противном случае, дымовое тестирование объявляется проваленным, и приложение уходит на доработку.
Аналогами дымового тестирования являются Build Verification Testing и Acceptance Testing, выполняемые на функциональном уровне командой тестирования, по результатам которых делается вывод о том, принимается или нет установленная версия программного обеспечения в тестирование, эксплуатацию или на поставку заказчику.
Для облегчения работы, экономии времени и людских ресурсов рекомендуется внедрить автоматизацию тестовых сценариев для дымового тестирования.
Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)
Сравнительная таблица дымового и санитарного тестирования
| Smoke testing (Дымовое тестирование) | Sanity testing (Проверка работоспособности, санитарное тестирование ) |
| Выполняется на начальных сборках программного продукта перед регрессионным тестированием | Проводится на сборках, которые успешно прошли дымовые испытания и перед циклом регрессионного тестирования |
| Тестируемая сборка может быть стабильной или нестабильной | Тестируемая сборка относительно стабильна |
| Мотивом является проверка стабильности новой собранной версии продукта в целом | Основной целью является проверка рациональности системы в деталях, чтобы приступить к более тщательному тестированию |
| Сбой при тестировании приводит к немедленному отказу от этой сборки программного обеспечения | Сбой в проверке работоспособности помещает сборку программного обеспечения в список отклоненных |
| Может выполняться как разработчиками, так и тестировщиками | Обычно проводится тестировщиками |
| Включает документацию и работу по сценариям | Не делает акцента на какой-либо документации и работу по сценариям |
| Можно рассматривать как общий вид тестирования, поверхностно покрывающий все основные функции без глубокого тестирования | Специализированная или более детально ориентированная методика тестирования, направлена на определенную функциональность или функцию |
| Может быть выполнено как автотестами, так и вручную | Обычно выполняется вручную |
| Экономит усилия команды тестировщиков и минимизирует время работы над дефектной сборкой программного обеспечения | Сохраняет время в условиях, когда его недостаточно для максимально обширного регрессионного тестирования |
Дымовое тестирование, также известное как Build Verification Testing, является благом для разработки программного обеспечения, поскольку его можно использовать в качестве метода проверки, который может гарантировать стабильность и 100% работоспособность продукта.
Короче говоря, это самый простой доступный метод для тестирования всех функций приложения.
Давайте подробно рассмотрим процесс дымового тестирования.
Что такое дымовое тестирование?
Вы листаете страницы, чтобы убедиться, что все в порядке. Правильно? Что ж, вы только что прошли дымовой тест на посылке.
Зачем нужны дымовые испытания?
Представьте себе ситуацию, когда у вас есть команда тестирования, состоящая из 10 человек.
Теперь, когда сборка готова, все начинают тестирование. Может возникнуть ситуация, когда либо ожидаемых изменений кода в сборке нет, либо даже некоторые основные функции нарушены.
Не зная об этом факте, все 10 тестировщиков начинают тестировать приложение и выявляют дефекты для обнаруженных сбоев.
Теперь, в конце концов, команда разработчиков может вернуться и сказать, извините, что это неправильная сборка, или команда QA может остановить тестирование, заявив, что существует слишком много проблем.
Но опять же 10 человек уже потратили на это свои 8 часов, что означает потерю 80 часов продуктивности. Кроме того, если проблема была обнаружена раньше, команда разработчиков могла бы начать работу над ней и решить ее раньше.
Это причина, по которой нам нужно провести дымовой тест, прежде чем переходить к полноценному циклу тестирования.
Преимущества дымового тестирования
Это помогает находить неисправности на ранних этапах жизненного цикла продукта.
Когда и как часто нам нужно проводить дымовые испытания?
Дымовое тестирование обычно занимает максимум 60 минут и должно проводиться для каждой новой сборки, каждого нового выпуска, даже если это означает ежедневное выполнение.
Когда продукт станет стабильным, вы можете даже подумать об автоматизации дымовых тестов и запуске его в конвейере CI. В конвейере CI / CD дымовой тест очень важен, потому что он предотвратит запуск нестабильной или сломанной сборки в производство.
Цикл дымового тестирования
Какие сценарии необходимо включить в дымовой тест?
Теперь, когда у нас есть представление о Smoke Testing, мы теперь поймем, какие сценарии необходимо включить в Smoke Testing. Читайте дальше, чтобы понять различные тестовые примеры и причину, по которой они являются частью набора Smoke Testing.
1) Проверка сборки : первым и самым важным шагом дымового теста является проверка сборки, номера сборки и доступности среды. Все усилия по тестированию будут потрачены впустую, если сборка неправильная.
2) Создание учетной записи : если ваше приложение предполагает создание пользователя, вам следует попытаться создать нового пользователя и проверить, успешно ли система позволяет вам это сделать. Это важный момент, который часто упускается из виду, поскольку тестировщики продолжают использовать старые учетные данные без тестирования для нового пользователя.
3) Вход в систему Выход : если это возможно в вашей SUT (тестируемая система), в рамках дымового теста вы должны попытаться успешно войти в систему со старыми и вновь созданными учетными данными. Также убедитесь, что вы можете успешно выйти из системы без каких-либо ошибок.
4) Критически важные для бизнеса функции : это очень важно. Для всех основных или критически важных функций мы должны провести простой тест, чтобы убедиться, что наиболее часто используемые функции не нарушены.
5) Сценарии интеграции: это самая важная часть дымового теста. Эффективность этой части зависит от понимания тестером интеграции системы. Например, если тестировщик знает, что какие-то данные текут из системы A в систему B, то он должен сделать это как часть дымового теста (любое значение 1). Это также делается для того, чтобы система не сломалась ни в одной из этих точек интеграции.
6) Добавить / изменить / удалить: данные всегда сохраняются в базе данных. Три основных операции в базе данных: добавление записи, редактирование записи и удаление записи. Таким образом, чтобы обеспечить надлежащее соединение с базой данных, в рамках дымового теста необходимо попытаться создать, отредактировать и удалить запись, которая применима в тестируемой системе.
Как сделать дымовое тестирование?
Обычно Smoke Testing выполняется вручную, чтобы убедиться, что навигация происходит плавно и не мешает функциональности.
Однако проведение дымовых испытаний может варьироваться от компании к компании в зависимости от требований.
После завершения сборки программного обеспечения оно переходит в QA, где будут выполнены критически важные функциональные тестовые примеры.
В случае сбоя программное обеспечение будет отправлено команде разработчиков, чтобы можно было внести в него необходимые исправления.
После исправления программное обеспечение снова пройдет дымовые испытания и будет сравниваться со старой сборкой.
Когда времени меньше и новая сборка готова к развертыванию, автоматизацию можно использовать для дымового тестирования.
Предварительно записанные тестовые примеры дыма могут быть запущены против сборки.
Если тест оказался неудачным, может быть сделано необходимое исправление, и программное обеспечение может быть развернуто в течение короткого промежутка времени.
Как запустить дымовое тестирование?
Кто будет проводить дымовой тест?
Обычно QA-лидер выполняет дымовое тестирование.
После того, как основная сборка программного обеспечения будет завершена, оно будет протестировано, чтобы определить, работает оно хорошо или нет.
Вся команда QA собирается вместе и обсуждает основные функции программного обеспечения, после чего будет проведен дымовой тест, чтобы выяснить его состояние.
Короче говоря, дымовой тест проводится в атмосфере разработки, чтобы убедиться, что сборка удовлетворяет требованиям.
Пример дымового испытания
Разница между тестом на дым и тест на вменяемость
Тестирование на работоспособность проводится для проверки того, что после исправления функциональные возможности работают правильно в соответствии с требованиями. Во время проверки работоспособности глубокое тестирование выполняться не будет.
Несмотря на то, что тестирование здравомыслия и дымовое тестирование могут показаться похожими, есть различия.
Дымовое тестирование.
Чтобы проверить критические функции
Проверить, работают ли новые функции или исправлены ошибки
Используется для проверки стабильности системы
Используется для проверки рациональности, чтобы перейти к более глубоким испытаниям
Выполняется как разработчиками, так и тестировщиками
Только для тестировщиков
Форма приемочного тестирования
Форма регрессионного тестирования
Сборка может быть стабильной и нестабильной при выполнении дымового тестирования
Относительно стабильна при выполнении проверки работоспособности
Все приложение протестировано
Критические компоненты проверены
Если все пункты рассмотрены, вы можете быть уверены, что у вас есть готовый хороший набор для дымовых тестов.
Мы всегда должны помнить о том, что дымовой тест не должен длиться более 60 минут.
См. также
Я хотел бы услышать твое мнение про дымовое тестирование Надеюсь, что теперь ты понял что такое дымовое тестирование,smoke testing и для чего все это нужно, а если не понял, или есть замечания, то нестесняся пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.