Простые ошибки могут быть фатальными для вашего сайта — особенно если Вы — SaaS (eng. Software as a Service) компания, как мы. Если пользователь заходит на Ваш сайт и не может справиться с простым заданием, таким как зарегистрироваться или сбросить свой забытый пароль, Вы рискуете потерять этого пользователя навсегда.
Мы испытали это на своей собственной шкуре. Безусловно, иметь своих людей в команде, которые тестируют приложение и ищут баги — это важно, но не всегда уместно или недостаточно тщательно. В этой статье, мы хотим представить Вам, гуманитариям, мир smoke-тестов.
Если все же у Вас останутся вопросы — восполнить пробелы вы сможете, посетив
Smoke-тестирование первоначально было придумано, чтобы объяснить как инженеры-электротехники проверяли работает ли их прибор — включали его и если дым шел…
Подождите, как это может быть применимо к приложениям?
Важность (и рентабельность) smoke-тестов, как правило, неизвестна для менеджеров-гуманитариев и соучредителей. Систематические smoke-тесты могут рассматриваться как неотъемлемая часть для предотвращения роста вероятности взлома. Они минимизируют вероятность того, что в Вашем веб-приложении или приложении для телефона произойдет сбой — и как все мы знаем, только одна неудача и вы можете потерять клиента навсегда.
Это вводное руководство о том, что это такое, как это может быть реализовано, какие ресурсы используются для его проведения и примеры, направляющие читателей.
Smoke-тесты созданы для того, чтобы проверить основную функциональность и должны быть неотъемлемой частью Вашего процесса тестирования. Они могут включать что-то простое, типа «Могу ли я зарегистрироваться?».
Smoke-тестирование помогает убедиться, что ни одна из основных и очевидных неудач не оставлена на волю случая. Не следует проводить более глубокий тест, пока вы не выполнили smoke-тесты на 100%, потому что они очищают программное обеспечение от фундаментальных ошибок.
Шаг 1: Решите, что надо тестировать
Определите, что Ваше приложение стремится достичь. Каковы наиболее очевидные «детские» шаги, которые необходимы, чтобы в него попасть? Каковы минимальные жизненно важные требования и в какой логической последовательности Вы их перечислите?
Создайте набор тестов. Набор тестов — это сгруппированная совокупность тест-кейсов (тестовых случаев), связанная определенным образом (например, по функциональности).
Smoke-тестирование не будет включать в себя переменные или вопросы вида «что если?». Оно предполагает только ответы да/нет, но прежде чем переходить к более подробному тестированию, все тест-кейсы должны быть пройдены с положительным результатом.
Давайте возьмем для примера создание интерактивного форума. Для того, чтобы он работал я должен:
- зарегистрироваться.
- создать Имя пользователя.
- загрузить фото на аватарку.
- писать сообщения.
- отвечать на сообщения.
Шаг 2: Записываем результаты в таблицу
Изображение выше — пример от нашей команды. Вы можете найти шаблон . Это необходимо для того, чтобы сохранить записи того, что у нас работает, а что нет — базовая организация сэкономит кучу времени в дальнейшем. Мы разделили наши результаты на пройдено, частично и провалено.
- Пройдено: все работает идеально.
- Частично: изначально вы можете не понимать, что некоторые действия могут быть еще подразделены, и поэтому одна часть работает, а другая — нет.
- Провалено: не работает.
Мы описали точные шаги, которые мы хотели воспроизвести, а затем, в следующей графе, добавили краткое описание того, что мы ожидаем на выходе. Пример:
Шаг 3: Автоматизируем smoke-тесты
Очень важно не принимать за аксиому то, что если какое-либо действие было пройдено один раз, оно будет всегда с положительным исходом. Smoke-тесты позволяют постоянно проверять, что основные функции не пострадали с течением времени или не были поломаны в течение долгого периода.
Не прекращай smoke-тестирование. Никогда.
Когда Ваш набор тест-кейсов для smoke-тестирования завершается с успешным исходом на 100%, подумайте об их автоматизации . Рекомендуемая частота проведения smoke-тестов — каждый день, если Ваша компания занимается разработкой каждый день.
Минимальная необходимость — проводите прогон smoke-тестов перед каждым релизом и после каждого патча.
Эмпирическое правило для smoke-теста:
- Минимальное время: 30 минут.
- Максимальное время: 60 минут.
В дальнейшей перспективе автоматизация smoke-тестов экономит время, но при прогоне одних и тех же тестов снова и снова человеческий глаз может перестать замечать детали, а машина нет.
What is Smoke Testing?
Smoke testing is defined as a type of software testing that determines whether the deployed build is stable or not. This serves as confirmation whether the QA team can proceed with further testing. Smoke tests are a minimal set of tests run on each build. Here is the cycle where smoke testing is involved
Smoke testing is a process where the software build is deployed to QA environment and is verified to ensure the stability of the application. It is also called as "Build verification Testing" or “Confidence Testing.”
In simple terms, we are verifying whether the important features are working and there are no showstoppers in the build that is under testing.
It is a mini and rapid regression test of major functionality. It is a simple test that shows the product is ready for testing. This helps determine if the build is flawed as to make any further testing a waste of time and resources.
The smoke tests qualify the build for further formal testing. The main aim of smoke testing is to detect early major issues. Smoke tests are designed to demonstrate system stability and conformance to requirements.
A build includes all data files, libraries, reusable modules, engineered components that are required to implement one or more product functions.
In this tutorial, you will learn-
When do we do smoke testing
Smoke Testing is done whenever the new functionalities of software are developed and integrated with existing build that is deployed in QA/staging environment. It ensures that all critical functionalities are working correctly or not.
In this testing method, the development team deploys the build in QA. The subsets of test cases are taken, and then testers run test cases on the build. The QA team test the application against the critical functionalities. These series of test cases are designed to expose errors that are in build. If these tests are passed, QA team continues with Functional Testing .
Any failure indicates a need to handle the system back to the development team. Whenever there is a change in the build, we perform Smoke Testing to ensure the stability.
Example : -New registration button is added in the login window and build is deployed with the new code. We perform smoke testing on a new build.
Who will do Smoke Testing
After releasing the build to QA environment, Smoke Testing is performed by QA engineers/QA lead. Whenever there is a new build, QA team determines the major functionality in the application to perform smoke testing. QA team checks for showstoppers in the application that is under testing.
Testing done in a development environment on the code to ensure the correctness of the application before releasing build to QA, this is known as Sanity testing. It is usually narrow and deep testing. It is a process which verifies that the application under development meets its basic functional requirements.
Sanity testing determines the completion of the development phase and makes a decision whether to pass or not to pass software product for further testing phase.
Why do we do smoke testing?
Smoke testing plays an important role in software development as it ensures the correctness of the system in initial stages. By this, we can save test effort. As a result, smoke tests bring the system to a good state. Once we complete smoke testing then only we start functional testing.
- All the show stoppers in the build will get identified by performing smoke testing.
- Smoke testing is done after the build is released to QA. With the help of smoke testing, most of the defects are identified at initial stages of software development.
- With smoke testing, we simplify the detection and correction of major defects.
- By smoke testing, QA team can find defects to the application functionality that may have surfaced by the new code.
- Smoke testing finds the major severity defects.
Example 1: Logging window: Able to move to next window with valid username and password on clicking submit button.
Example 2: Userunable to sign out from the webpage.
How to do Smoke Testing ?
Smoke Testing is usually done manually though there is a possibility of accomplishing the same through automation. It may vary from organization to organization.
Manual Smoke testing
In general, smoke testing is done manually. It approaches varies from one organization to other. Smoke testing is carried to ensure the navigation of critical paths is as expected and doesn"t hamper the functionality. Once the build is released to QA, high priority functionality test cases are to be taken and are tested to find the critical defects in the system. If the test passes, we continue the functional testing. If the test fails, the build is rejected and sent back to the development team for correction. QA again starts smoke testing with a new build version. Smoke testing is performed on new build and will get integrated with old builds to maintain the correctness of the system. Before performing smoke testing, QA team should check for correct build versions.
Перевод разбавлен размышлениями и дополнениями автора из своего опыта
О чём это всё
Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.В этой статье я хотел бы внести ясность и объяснить разницу между этими видами тестирования и попробовать разобраться, провести границы (хоть и условные) где заканчивается один вид тестирования, и начинается другой.
Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?
Строго говоря, вы всё равно сможете проводить тестирование, даже при том что не сможете точно сказать, в чём же разница. Можно даже не задумываться о разграничении, каким именно видом тестирования вы сейчас заняты. Но всё же, чтобы расти над собой в профессиональном смысле, нужно знать что вы делаете, зачем, и насколько правильно вы это делаете.
Ликбез
Ниже приведены краткие определения видов тестирования, которые мы сегодня сравниваем:- Дымовые тесты : выполняются каждый раз, когда мы получаем новый билд (версию), проекта (системы) на тестирование, при этом считая её относительно нестабильной. Нам нужно убедиться что критически важные функции 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 в следующем билде отрабатывает как задумывалось.
Подведём итог
Надеюсь, что после чтения данной статьи, у вас появится ясность в определении какой вид тестирования вы используете на каком этапе, и в чём разница между этими видами тестирования. Как и было упомянуто вначале, граница между этими понятиями весьма условная и остаётся на ваше усмотрение в рамках проекта.UPD
:
Часто «тестирование согласованности» или «тестированием на вменяемость», называют термином «санитарное тестирование». Думаю что это пошло из-за фонетических свойств английского слова sanity, схожего по звучанию с чем-то «санитарным». Гугл транслейт вносит ясность . В интернете встречаются оба варианта. Относительно данной статьи прошу считать «санитарное» тестирование как «тестирование на согласованность».
Спасибо за наводку
Проводить дымовое и санитарное тестирование начинают сразу же после выхода очередной версии проекта. Для многих молодых тестировщиков этот процесс кажется абсолютным хаосом. Узнал себя? Тогда эта статья для тебя. Сейчас мы рассмотрим определения дымового и санитарного тестирования, а также покажем разницу между ними на легких для понимания примерах.
Дымовое тестирование:
Дымовое тестирование проводят для того, чтобы убедиться в пригодности полученного билда к тестированию. Его также называют проверкой “нулевого дня”.
Именно этот вид тестирования не даст потратить время впустую. Логично, что тестирование всего приложения не имеет смысла, если есть проблемы с ключевыми характеристиками и не исправлены критичные баги.
Санитарное тестирование:
Санитарное тестирование проводят на стадии релиза для проверки основного функционала приложения. Дальше обычно не углубляются. Такое тестирование иногда называют сокращенной версией регрессионного тестирования.
Когда сроки релиза поджимают, выполнить тщательное регрессионное тестирование практически невозможно. В этом случае с работой отлично справляется санитарное тестирование, которое проверяет работу главных функций приложения.
Пример для лучшего понимания разницы между дымовым и санитарным тестированием:
Есть проект, для которого запланирован первоначальный релиз. Команда разработчиков выпускает билд на тестирование, команда тестировщиков начинает работу. Самое первое тестирование — это тестирование на пригодность. Нужно выяснить, можно работать с этой версией или нет. Это и есть дымовое тестирование. Если команда дает добро на дальнейшую работу с билдом, он отправляется на более глубокие стадии тестирования. Представим, что у билда есть три модуля: “Логин”, “Админ” и “Сотрудник”. Команда тестировщиков проверяет работоспособность исключительно основных функций каждого из модулей, не углубляясь в проверку частностей. Это будет санитарное тестирование.
Еще несколько различий между дымовым и санитарным тестированием:
- Дымовое тестирование проводится и разработчиками, и тестировщиками;
- Санитарное тестирование проводится только тестировщиками.
- Дымовое тестирование охватывает весь основной функционал приложения от начала до конца;
- Санитарное тестирование проверяет только определенный компонент приложения.
- Дымовое тестирование проходит как стабильный, так и не стабильный билд;
- Санитарное тестирование проходит относительно стабильная версия сборки.
Кирилл Флягин, геймдизайнер, QA Lead
Проведем летнюю аналогию с этими видами тестирования. Допустим, вы хотите купить арбуз. Дымовое тестирование — это когда вы проверяете его визуально, смотрите на полоски, сжимаете, стучите, оцениваете. Есть мастера, которые умудряются так купить действительно вкусную ягоду. В санитарном тестировании вы вырезаете пирамидку в верхней части и проверяете ее цвет (как один из компонентов), при этом совсем не знаете, такой ли арбуз весь. Но за вырезанную часть вы полностью уверены.
Означает минимальный набор тестов на явные ошибки . «Дымовой тест» обычно выполняется самим программистом; не проходящую этот тест программу не имеет смысла отдавать на более глубокое тестирование.
Примеры
- Ошибки инсталляции: если программный продукт не устанавливается, его тестирование, скорее всего, окажется невозможным.
- Ошибки при соединении с базой данных, актуально для архитектуры клиент-сервер .
История
Первое своё применение этот термин получил у печников, которые, собрав печь , закрывали все заглушки, затапливали её и смотрели, чтобы дым шёл только из положенных мест.
Повторное «рождение» термина произошло в радиоэлектронике. Первое включение нового радиоэлектронного устройства, пришедшего из производства, совершается на очень короткое время (меньше секунды). Затем инженер руками ощупывает все микросхемы на предмет перегрева. Сильно нагревшаяся за эту секунду микросхема может свидетельствовать о грубой ошибке в схеме. Если первое включение не выявило перегрева, то прибор включается снова на большее время. Проверка повторяется. И так далее несколько раз. Выражение «smoke-test» используется инженерами в шуточном смысле, так как появления дыма, а значит и порчи частей устройства, стараются избежать.
Автоматизация
Smoke Tests легче автоматизировать, чем более глубокое и интеллектуальное тестирование. Автоматизация снижает количество ручного труда и поэтому позволяет проводить эти тесты чаще. Чем чаще выполняются тесты, тем раньше становится известно о проблемах, выявляемых этими тестами. Чем раньше становится известно о проблеме, тем легче её устранить. Автоматизация тестирования часто выполняется с помощью средств непрерывной интеграции .
Напишите отзыв о статье "Smoke test"
Ссылки
- на Jargon File (англ.)
- msdn.microsoft.com/ru-ru/library/ms182613(VS.90).aspx - Правила по кратким тестам от Майкрософт.
Отрывок, характеризующий Smoke test
Весь день она жила только надеждой того, что ночью она уввдит его. Но теперь, когда наступила эта минута, на нее нашел ужас того, что она увидит. Как он был изуродован? Что оставалось от него? Такой ли он был, какой был этот неумолкавший стон адъютанта? Да, он был такой. Он был в ее воображении олицетворение этого ужасного стона. Когда она увидала неясную массу в углу и приняла его поднятые под одеялом колени за его плечи, она представила себе какое то ужасное тело и в ужасе остановилась. Но непреодолимая сила влекла ее вперед. Она осторожно ступила один шаг, другой и очутилась на середине небольшой загроможденной избы. В избе под образами лежал на лавках другой человек (это был Тимохин), и на полу лежали еще два какие то человека (это были доктор и камердинер).Камердинер приподнялся и прошептал что то. Тимохин, страдая от боли в раненой ноге, не спал и во все глаза смотрел на странное явление девушки в бедой рубашке, кофте и вечном чепчике. Сонные и испуганные слова камердинера; «Чего вам, зачем?» – только заставили скорее Наташу подойти и тому, что лежало в углу. Как ни страшно, ни непохоже на человеческое было это тело, она должна была его видеть. Она миновала камердинера: нагоревший гриб свечки свалился, и она ясно увидала лежащего с выпростанными руками на одеяле князя Андрея, такого, каким она его всегда видела.
Он был таков же, как всегда; но воспаленный цвет его лица, блестящие глаза, устремленные восторженно на нее, а в особенности нежная детская шея, выступавшая из отложенного воротника рубашки, давали ему особый, невинный, ребяческий вид, которого, однако, она никогда не видала в князе Андрее. Она подошла к нему и быстрым, гибким, молодым движением стала на колени.
Он улыбнулся и протянул ей руку.
Для князя Андрея прошло семь дней с того времени, как он очнулся на перевязочном пункте Бородинского поля. Все это время он находился почти в постояниом беспамятстве. Горячечное состояние и воспаление кишок, которые были повреждены, по мнению доктора, ехавшего с раненым, должны были унести его. Но на седьмой день он с удовольствием съел ломоть хлеба с чаем, и доктор заметил, что общий жар уменьшился. Князь Андрей поутру пришел в сознание. Первую ночь после выезда из Москвы было довольно тепло, и князь Андрей был оставлен для ночлега в коляске; но в Мытищах раненый сам потребовал, чтобы его вынесли и чтобы ему дали чаю. Боль, причиненная ему переноской в избу, заставила князя Андрея громко стонать и потерять опять сознание. Когда его уложили на походной кровати, он долго лежал с закрытыми глазами без движения. Потом он открыл их и тихо прошептал: «Что же чаю?» Памятливость эта к мелким подробностям жизни поразила доктора. Он пощупал пульс и, к удивлению и неудовольствию своему, заметил, что пульс был лучше. К неудовольствию своему это заметил доктор потому, что он по опыту своему был убежден, что жить князь Андрей не может и что ежели он не умрет теперь, то он только с большими страданиями умрет несколько времени после. С князем Андреем везли присоединившегося к ним в Москве майора его полка Тимохина с красным носиком, раненного в ногу в том же Бородинском сражении. При них ехал доктор, камердинер князя, его кучер и два денщика.