что такое санитарное тестирование

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-тестирование или проверка сборки проводится для того, чтобы до запуска продукта убедиться, что всё работает стабильно и отвечает требованиям заказчика. Оно проводится при каждой новой сборке. У этого вида тестирования много преимуществ: оно помогает заметить дефекты на раннем этапе, повысить качество системы и экономит время.

Источник

говориМ о тестировании
простым языком

Виды тестирования по целям: тестирование, связанное с изменениями

Именно после таких правок продукт необходимо снова протестировать. Давайте посмотрим, как именно это можно сделать.

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

Как же проверить все эти внесенные изменения? Давайте разбираться.

Существует несколько видов тестирования, связанного с изменениями:
1. Подтверждающее тестирование (Re-testing)
2. Регрессионное тестирование (Regression Testing)
3. Дымовое тестирование (Smoke Testing)
4. Санитарное тестирование (Sanity Testing)
5. Тестирование сборки (Build Verification Test)

Давайте разберем их более подробно.

Подтверждающее тестирование (Re-testing)

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

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

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

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

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

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

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

Давайте представим это визуально.

Есть продукт. Он состоит из множества различных частей.

В одной из частей был баг и разработчик его исправил. То есть были внесены изменения в одну из частей программы (на рисунке выделено зеленым).

Данные изменения могли тем или иным образом отразиться и на работе других частей продукта. На рисунке выделено красным.

Либо может быть ситуация, когда в продукте появляется новый функционал. И его работа может повлиять на старый.

То есть нам нужно проверить работу старого функционала после исправления старого кода и/или написания нового. В этом и заключается регрессионное тестирование.

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

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

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

Данный вид тестирования определяет общее состояние качества продукта.

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

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

Данный тип тестирования позволяет на начальном этапе выявить основные быстро находимые критические дефекты.

Санитарное или Санити тестирование (Sanity Testing)

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

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

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

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

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

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

Разница

Итак, на сегодняшний момент наши знания о видах тестирования выглядят следующим образом.

Источник

Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA

Онлайн-тренинги

Что пишут в блогах (EN)

Blogposts:

Разделы портала

Про инструменты

Оригинальная публикация: http://habr.com/post/358142/

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

О чём это всё

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

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

Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?

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

Ликбез

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

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

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

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

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

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

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

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

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

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

Источник

Тестирование в здравом уме | Тестирование программного обеспечения

Sanity Testing — это разновидность регрессионного тестирования. Проверка работоспособности выполняется, чтобы убедиться, что сделанные изменения в коде работают должным образом. Проверка работоспособности — это остановка, чтобы проверить, можно ли продолжить тестирование сборки. Во время процесса проверки работоспособности команда фокусируется на проверке функциональности приложения, а не на детальном тестировании. Проверка работоспособности, как правило, выполняется на сборке, где требуется немедленное развертывание, как исправление критической ошибки.

Функциональность Sanity Testing:
Основная функциональность проверки работоспособности заключается в том, чтобы определить, что изменения или предлагаемая функциональность работают так, как ожидалось. Если проверка работоспособности не пройдена, команда тестирования отклоняет программный продукт, чтобы сэкономить время и деньги. Он выполняется только после того, как программный продукт прошел тест на дым, и группа обеспечения качества приняла его для дальнейшего тестирования.

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

Особенности Sanity Testing:

Преимущества Sanity Testing:

Источник

Пройти гигиеническое обучение и аттестацию

III. Технология поиска необходимых для обучения материалов.

Перечень групп работников, подлежащих гигиеническому обучению и аттестации:

1. Гигиеническое обучение заведующих и воспитателей детских дошкольных учреждений

2. Гигиеническое обучение помощников воспитателей детских дошкольных учреждений

3. Гигиеническое обучение начальников, воспитателей, вожатых детских оздоровительных лагерей

4. Гигиеническое обучение технического персонала образовательных учреждений

5. Гигиеническое обучение педагогических работников образовательных учреждений

6. Гигиеническое обучение работников пищеблоков детских оздоровительных лагерей

7. Гигиеническое обучение работников пищеблоков детских дошкольных учреждений

8. Гигиеническое обучение инженерно-технических работников работающих с пестицидами и агрохимикатами

9. Гигиеническое обучение рабочих профессий работающих с пестицидами и агрохимикатами

10. Гигиеническое обучение работников кондитерских производств

11. Гигиеническое обучение работников молокоперерабатывающей промышленности

12. Гигиеническое обучение работников мясо- и птицеперерабатывающей промышленности

13. Гигиеническое обучение работников общественного питания

14. Гигиеническое обучение работников продовольственной торговли

15. Гигиеническое обучение работников хлебопекарной и макаронной промышленности

16. Гигиеническое обучение преподавателей ВУЗов

17. Гигиеническое обучение студентов ВУЗов

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

19. Гигиеническое обучение работников парикмахерских

20. Гигиеническое обучение работников фармацевтических и аптечных учреждений

21. Гигиеническое обучение медицинских работников, кроме младшего мед. персонала

22. Гигиеническое обучение горничных и уборщиц гостиниц и общежитий

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

24. Гигиеническое обучение работников бань и прачечных

25. Гигиеническое обучение работников водопроводно-канализационного хозяйства

27. Гигиеническое обучение работников торговли промышленными товарами

28. Гигиеническое обучение работников плавательных бассейнов