Примеры smoke test. Связанные с изменениями виды тестирования. Определение группы сборки

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

- Дымовое тестирование (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.

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.

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

Практика применяемая, к примеру, в 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), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.

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

Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается 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 в следующем билде отрабатывает как задумывалось.

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

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

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

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

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

Проводить дымовое и санитарное тестирование начинают сразу же после выхода очередной версии проекта. Для многих молодых тестировщиков этот процесс кажется абсолютным хаосом. Узнал себя? Тогда эта статья для тебя. Сейчас мы рассмотрим определения дымового и санитарного тестирования, а также покажем разницу между ними на легких для понимания примерах.

Дымовое тестирование:

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

Именно этот вид тестирования не даст потратить время впустую. Логично, что тестирование всего приложения не имеет смысла, если есть проблемы с ключевыми характеристиками и не исправлены критичные баги.

Санитарное тестирование:

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

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

Есть проект, для которого запланирован первоначальный релиз. Команда разработчиков выпускает билд на тестирование, команда тестировщиков начинает работу. Самое первое тестирование — это тестирование на пригодность. Нужно выяснить, можно работать с этой версией или нет. Это и есть дымовое тестирование. Если команда дает добро на дальнейшую работу с билдом, он отправляется на более глубокие стадии тестирования. Представим, что у билда есть три модуля: “Логин”, “Админ” и “Сотрудник”. Команда тестировщиков проверяет работоспособность исключительно основных функций каждого из модулей, не углубляясь в проверку частностей. Это будет санитарное тестирование.

Еще несколько различий между дымовым и санитарным тестированием:

• Дымовое тестирование проводится и разработчиками, и тестировщиками;
• Санитарное тестирование проводится только тестировщиками.

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

• Дымовое тестирование проходит как стабильный, так и не стабильный билд;
• Санитарное тестирование проходит относительно стабильная версия сборки.

Кирилл Флягин, геймдизайнер, QA Lead

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