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

Негативное тестирование – суть метода и его главные приемы

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

Позитивное тестирование

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

Негативное тестирование

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

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

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

В каких случаях требуется негативное тестирование? К примеру:

1. Пользователь нажал кнопку «ОК», но не ввел данные.
2. Введенные данные превышают допустимое количество знаков.
3. Имя содержит числовые значения.
4. В имени есть специальный символ, а приложение этого не предвидит.
5. Использованы недопустимые слова.

Увидеть, как в вышеперечисленных случаях ведет себя программное обеспечение можно с помощью негативного тестирования.
‍

Основные методы написания негативных тестов

Как определить максимальное количество негативных сценариев? Два наиболее широко используемых метода определения негативных сценариев тестирования включают:

— Анализ граничных значений;

Что такое «анализ граничных значений»?

Анализ граничных значений — это процесс тестирования между крайними точками или границами входных значений. Крайние значения (например, Start-End, Lower-Upper, Maximum-Minimum, Just Inside-Just Outside) называются граничными, а тестирование называется «анализом граничных значений». Основная идея этого подхода состоит в следующем — нужно выбрать значения входных переменных на их:

• Минимуме;
• Чуть выше минимума;
• Номинальном значении;
• Чуть ниже максимума;
• Максимуме.
  ‍

Что такое «разделение эквивалентности»?

Входные данные домена делятся на разные классы эквивалентности. Этот метод позволяет взять все возможные тесты и поместить их в классы. Во время тестирования из каждого класса выбирается одно тестовое значение. Если вы тестируете поле ввода, куда можно вводить числа от 1 до 1000, нет смысла писать тысячи тестов для всех действительных входных чисел. Тесты можно разделить на классы согласно трем наборам входных данных.

1. Класс входных данных для всех допустимых входных данных.
2. Класс входных данных со всеми значениями за нижним пределом.
3. Входные данные с любым значением больше 1000.
   ‍

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

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

Негативное тестирование в действии

Представим следующую ситуацию — у вас есть экран входа в приложение с двумя текстовыми полями. В первое текстовое поле необходимо ввести имя пользователя. Во второе — пароль. К вводу данных есть конкретные требования. К примеру, имя пользователя в первом поле не может состоять только из символов. Кроме того, оно не может оставаться пустым (это же требование распространяется и на второе текстовое поле). Пароль может включать любую комбинацию букв (заглавных или строчных) или цифр от 0 до 9. Использовать другие символы нельзя. Максимальное количество символов для обоих полей — 10.
‍

Как, в таком случае, выглядит негативное тестирование?

• Попробуйте ввести имя пользователя, состоящее из цифр и символов или только символов: 123 * _ ;
• Создайте пароль, включающий специальные символы и пробелы: \
• Оставьте оба поля пустыми;
• Введите более 10 символов в оба текстовых поля.

Наша цель – посмотреть, как приложение реагирует на непредвиденное поведение и нестандартные ситуации. Для этого нужно испробовать различные сценарии. Написание негативных тестов — процесс, требующий креативного подхода и творческого мышления. По сути, вам необходимо представить, как можно «сломать» приложение и попытаться это сделать. Можно отталкиваться от требований и идти им наперекор, но лучше не делать этого напрямую, поскольку тогда существует риск, что проведенное вами тестирование окажется позитивным, а не негативным.

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

Андрей Мельничук

Автор. Пишет о компьютерной технике, электронике и ИТ, делает аналитические обзоры.

Негативные тесты для чайников

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

В идеале к негативным проверкам тестировщики переходят уже после позитивных.

Простейший пример: форма регистрации. Если мы вводим корректные данные и нажимаем кнопку «отправить», те должны успешно передаваться на сервер. Такая проверка называется позитивной.

А противоположной этому будет негативная проверка: к примеру, ввод в поле регистрации некорректного е-мэйл адреса типа ivanov#mail.ry.

Ожидаемых результатов в негативном тестировании может быть несколько:

1. Fail — этот результат мы получаем, когда система не знает, как реагировать на неожиданный поворот событий. Разработчики не добавили в продукт ответна негативный тест.
2. Success — разработчики заложили реакцию на негативный тест. Например, всплывающее окно-предупреждение о некорректно заполненной форме. В таком случае мы будем ожидать появления окна после негативной проверки.

Еще немного о негативном тестировании из нашей преподавательской практики.

Одному студенту была не понятна разница между багом и негативным тестом в нашем тренажере-калькуляторе. Для обучения начинающих тестировщиков мы используем собственноручно написанный кредитный калькулятор. В него для расчета кредита по условиям можно ввести сумму не менее 100 000 рублей.

Ввод в калькулятор меньшей суммы (например, 99 000) считается негативным тестом, а вот то, что калькулятор продолжает работать при таких условиях — уже баг.

Иногда в начале обучения бывает сложно уловить эту тонкую грань: где — еще тест, а где — уже баг.

Вот как объяснил это наш эксперт, тренер и автор вебинаров курса ПОИНТ Игорь Савченко:

«Этап тестирования и этап написания тестов — это два разных этапа.

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

Сейчас вы опираетесь на то, что уже «щупали» продукт (калькулятор) и знаете, как он себя ведет. Это этап тестирования.

А написание тестов идет до этапа тестирования, то есть логично, что мы составляем тесты на основании знаний о продукте, но не привязываем к ним фактическое поведение.

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

К выяснению фундаментальной разницы подключились и остальные ученики:

Кстати, иногда очень полезно сравнить QA-термины с более понятными вещами! Воспринимать новое тогда становится заметно легче.

Пример с шарлоткой крут! Можно немного его расширить: если по рецепту в яблочный пирог входят яйца, мука, сахар и яблоки, а мы вместо сахара добавили перец, это негативная проверка. Если при этом пирог не в курсе, что его поперчили, и продолжает быть сладким, это баг!

А вы бы хотели научиться тестированию ПО в команде с неравнодушными сокурсниками и тренерами, которые всегда поддержат, ответят, объяснят и «на пальцах», и серьезно? Присоединяйтесь к экспресс-курсу для новичков Jedi Point. Старт 24 апреля!

Дата публикации: 18.04.2023

Последние новости

• Стажировка мечты. Где брать опыт начинающему тестировщику
• Нашла работу мечты за месяц. История выпускницы курса для начинающих тестировщиков
• Как проходит рабочий день тестировщика
• QA-word of the day: maintainability
• Наши секреты: почему надо выбрать нас
• Лучшие курсы по тестированию ПО в ноябре 2023
• Тестировщик: кто это и как им стать

Негативное тестирование: когда, зачем, сколько? Часть 2.

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

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

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

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

Общепринятое определение звучит так:

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

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

С позитивными кейсами ответ однозначный: ввели «хорошие» данные — получили результат “success”. А если вводим «плохие»? Здесь мы столкнулись с некоторой неоднозначностью. У негативных проверок может быть два результата:

1. на данный ввод у системы есть ответ в виде сообщения/контроля;
2. система не знает, как реагировать на введенные данные.

То есть у системы есть как минимум три реакции на наши действия по вводу данных:

1. Действие: создание сущности, переход на новый шаг и т.п.
2. Контроль: сообщение с контролем, блокировка дальнейших действий и т.п.
3. Отказ: возникает исключение Exception, 404-ой ошибки и т.п.

Исходя из написанного выше, немного усложним формулировки и станем рассматривать определения «позитива» — «негатива» не только со стороны вводимых данных, но и со стороны полученного результата. В этом случае появится еще один тип проверок: условно-негативные. К условно-негативным будем относить все проверки, в которых при введении некорректных данных получаем успешный, с точки зрения логики, результат (сообщение об ошибке).

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

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

Проект пока еще как младенец. ЦА вроде бы изучена, аналитики написали первые варианты Технических Заданий (ТЗ), разработчики уже сделали первый вариант продукта и позвали нас тестировать.

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

На проекте исправлены все «детские болячки», учтены замечания с предыдущего уровня. В ТЗ, при необходимости, добавлены новые контроли. Проект стал похож на тинейджера — почти взрослый, все знает и умеет, но жизненного опыта недостаточно, чтобы справиться с нестандартными ситуациями. На этом этапе более внимательно тестируем позитивные состояния, проводя сложные проверки и применяя различные техники тест-дизайна. При этом уделяем не меньшее внимание и условно-негативным проверкам, ведь наша задача — убедиться, что на каждое действие есть реакция из п.1 или п.2, то есть не возникает отказов.

Проект готов! Он перешел с тестового стенда на прод, стабильно работает и живет взрослой жизнью. Все ошибки давно исправлены, а узкие места известны. На этом этапе мы чаще всего проводим регрессионное тестирование, используя в основном позитивные проверки. Что касается негатива, то оптимальным для данного этапа будет проверка контролей (то есть условно-негативные кейсы) с помощью автотестов. Тем самым на этом этапе время, потраченное на ручное негативное тестирование, минимально и только в случае падения автотестов.

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

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

Например, куда отнести следующий кейс (все совпадения случайны и, наверняка, он был учтен “Амазоном”, но давайте пофантазируем): покупатель зашел в магазин Amazon Go за покупками, съел сэндвич на месте, вернул коробочку из-под него на место и вышел с пустыми руками, без оплаты покупки. С точки зрения линейного процесса и реализованного кода все отработало идеально. С точки зрения бизнес-процесса — это явный fail. Задумались? Куда бы вы отнесли данный кейс? Может, у вас есть свои примеры, доказывающие, что в этом мире нет ничего однозначно черного или белого? Поделитесь в комментариях ��

Дата публикации: 19.03.2019

Последние новости

• Стажировка мечты. Где брать опыт начинающему тестировщику
• Нашла работу мечты за месяц. История выпускницы курса для начинающих тестировщиков
• Как проходит рабочий день тестировщика
• QA-word of the day: maintainability
• Наши секреты: почему надо выбрать нас
• Лучшие курсы по тестированию ПО в ноябре 2023
• Тестировщик: кто это и как им стать

Позитивное и негативное тестирование

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

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

Что такое позитивное тестирование?

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

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

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

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

Это можно понять из схематичного примера, описанного ниже:

A – это начальная точка, а B – конечная точка. Существует два пути из точки А в точку В. Маршрут 1 – это обычный путь, а маршрут 2 – альтернативный. Таким образом, в этом случае для тестирования “счастливого пути” (Happy Path Testing) нужно пройти от точки A до B по маршруту 1, а для тестирования альтернативного пути нужно пройти от A до B по маршруту 2. Заметьте, что результат в обоих случаях одинаков.

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

Негативное тестирование (Negative Testing), также называемое “Error path testing”, “Failure testing”, обычно проводится для обеспечения стабильности приложения.

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

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

Рассмотрим пример. Допустим, вам нужно написать негативные тест-кейсы для проверки шариковой ручки. Основное предназначение ручки – возможность писать на бумаге.

Тест-кейсы негативного тестирования могут быть следующими:

• Смените материал, на котором должна писать ручка, с бумаги на ткань или кирпич, и посмотрите, будет ли она по-прежнему писать.
• Опустите ручку в жидкость и проверьте, пишет ли она.
• Замените стержень ручки на пустой и проверьте, перестанет ли она писать.

Практические примеры

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

Первое окно

В первом окне пользователь должен ввести текстовые значения:

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

Требования:

• Текстовое поле “Name” является обязательным.
• “Description” не является обязательным.
• Поле “Name” может содержать только символы a-z и A-Z. Цифры и специальные символы не допускаются.
• Длина поля “Name” – не более 10 символов.

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

Позитивные сценарии тестирования:

1. ABCDEFGH (проверка верхнего регистра в пределах лимита символов).
2. abcdefgh (проверка нижнего регистра в пределах лимита символов).
3. aabbccddmn (проверка лимита символов).
4. aDBcefz (проверка сочетания букв в верхнем и нижнем регистре в пределах лимита символов).
5. … и так далее.

Негативные сценарии тестирования:

1. ABCDEFGHJKIOOOOOKIsns (превышение лимита в 10 символов для поля “Name”)
2. abcd1234 (числовые значения, введенные в поле “Name”)
3. В поле “Name” ничего не введено
4. sndddddwwwww_ (специальные символы в поле “Name”)
5. … и так далее.

Второе окно

Во втором окне пользователь должен вводить только числовые значения.

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

Требования:

• ID должен быть числом в диапазоне 1-250
• ID является обязательным.

Вот несколько позитивных и негативных сценариев тестирования для этого конкретного окна.

Позитивные сценарии тестирования:

1. 12 (ввод действительного значения в указанном диапазоне).
2. 1, 250 (ввод граничных значений указанного диапазона).

Негативные сценарии тестирования:

1. Ab (ввод текста вместо чисел).
2. 0, 252 (ввод значений вне допустимого диапазона).
3. Пустой ввод.
4. -2 (ввод значений вне диапазона).
5. +56 (ввод допустимого значения со специальным символом).

Советы по написаю позитивных и негативных тест-кейсов

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

Кроме того, вы могли заметить закономерность в том, как сценарии делятся на 2 категории. В обоих приведенных выше случаях есть два основных метода, которые легли в основу разработки достаточного количества как позитивных, так и негативных тест-кейсов:

• Анализ граничных значений
• Эквивалентное разбиение

Анализ граничных значений

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

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

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

Эквивалентное разбиение

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

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

В примере, приведенном выше, значения можно поделить, скажем, на два класса:

• Значения от -255 до -1 в одном классе
• Значения от 0 до 255 в другом классе

Заключение

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

В то время как позитивное тестирование гарантирует, что бизнес-показатели продукта валидны, негативное тестирование гарантирует, что поставляемое программное обеспечение не имеет дефектов.

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

Похожие записи:

1. Руководство по тестированию на проникновение
2. Что такое системное тестирование?
3. Что такое бета-тестирование?
4. Регрессионное тестирование