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

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

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

Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.

Где: Кострома / онлайн

2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.

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

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

Blogposts:

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

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

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

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

О чём это всё

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

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

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

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

Ликбез

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

Нагрузочное тестирование (Load Testing) в Тестировании ПО

Софтверные разработчики, в связи с форсированным развитием IT- отрасли и аппаратных возможностей, вынуждены обеспечивать бесперебойную работу своих детищ в условиях неимоверных нагрузок. Чисто коммерчески: клиент, столкнувшийся с недостатками производительности приложения или программы, в условиях широкого выбора, вероятнее всего откажется от спровоцированного продукта. Решить проблему внезапного отказа может решить проведение испытаний ПО в условиях максимальных нагрузок (нагрузочное тестирование). Качественное его проведение должно быть золотым стандартом у желающих гарантировать стабильность прогамм.

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

«Load Testing» — нагрузочное тестирование в переводе на английский. Синоним – тестирование производительности. Программно проводится имитация деятельности нескольких, определённого количества пользователей представляемого программного продукта (Performance Testing).

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

Нагрузочное тестирование, в первую очередь, является получение серьёзных аналитических данных. Без наличия продвинутых знаний программирования нельзя полностью организовать тестирование в автоматическом режиме. Во-вторых — учитывая многопользовательность продукта, необходимы знания сетей (протоколы, разнообразие серверов, баз данных). Третье для разных целей относительно работы продукта под нагрузкой применяются соответствующие разновидности нагрузочного тестирования.

Профессия QA Engineer. Кто такой Тестировщик?

QA Engineer что это — это такая же профессия, работа по найму в IT как и многие другие о которых вы скорее всего слышали и знаете, к примеру, такие как программист или аналитик. QA Engineer выполняет весь обьем работ связанный с тестированием ПО на проекте.

Чем же занимается QA Engineer?

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

Уровни квалификации и опыта у Тестировщика (QA Engineer)

Обычно Тестировщиков делят на 4 основные категории:

Trainee QA Engineer

Junior QA Engineer

Middle QA Engineer

Senior QA Engineer

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

Баг репорт (Bug Report) или заведение бага в тестировании ПО?

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

Существует различное множество баг-трекинговых систем, которые позволяют нам не только создавать задачи, менять их статусы но и создавать баг репорты. Самые распространенные на сегодняшний день это Redmine, Bugzilla, Mantis, JIRA

Пример того как выглядит список баг репортов в JIRA:

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

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

Основные Виды тестирования Програмного Обеспечения

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

Приемочное тестирование (Acceptance testing)

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

Функциональное тестирование (Functional testing)

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

Смоук тестирование (Smoke testing)

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

Тестирование Безопасности (Security testing)

Проверка прав доступа, невозможность захода в программу посторонним лицам, SQL инъекции, XSS атаки. Проверяем что приложение соответствует необходимым требованиям к безопасности

Источник

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

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

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

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

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

Существует несколько видов тестирования, связанного с изменениями:
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)

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

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

Разница

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

Источник

В чём разница Smoke, Sanity, Regression, Re-test и как их различать?

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

О чём это всё

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

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

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

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

Ликбез

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

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

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

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

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

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

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

Источник

Дымовое и санитарное тестирование: понятия и характерные отличия

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

Дымовое тестирование (англ. smoke testing)

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

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

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

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

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

Ключевые преимущества дымовых тестов

Санитарное тестирование (англ. sanity testing)

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

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

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

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

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

Ключевые особенности санитарного тестирования

Преимущества санитарного тестирования

Недостатки

Сравнение дымового и санитарного тестирования

Наглядные примеры использования данных тестов

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

Пример дымового тестирования

Допустим, в проверяемом ПО есть 5 модулей, а именно:

То есть, внутри данных модулей QA проводит тестирование, проверяя основную функциональность этих модулей, а точнее:

Пример санитарного тестирования

Снова представим, что есть 5 модулей:

При тестировании был найден дефект на странице авторизации. К примеру, поле для ввода пароля воспринимает комбинацию исключительно из 6 символов, что категорически не соответствует ТЗ, где указанно, что пароль может быть от 4 символов.

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

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

Данные тесты проводятся только тогда, когда сборка ПО успешно прошла дымовые проверки и валидацию для последующих испытаний.

Источник