Представьте, что перед вами стоит задача проверки поля в форме. С чего начнете? Наверняка найдутся те, кто бросится ломать форму и вводить некорректные данные. Но большинство упомянет о необходимости проведения сначала позитивных проверок, ведь прежде необходимо убедиться, что поле в принципе способно обрабатываться. И уже потом вы перейдете к негативным.
И будете правы. Но только в теории.
На практике же не существует проектов, в которых нужно тестировать со всех сторон единственное поле. Таких полей может быть тысячи и сроки дедлайна (в нашем мире, где они обычно обозначены как «вчера») порой не позволяют провести полностью даже позитивные проверки, не говоря о негативных.
Как быть? Какой приоритет должен быть у негативных проверок? А, может, не проверять негатив вообще? Как это часто бывает, универсального ответа нет, но я постараюсь рассказать о том, как тестирую сама.
Для начала давайте разберемся с терминами. Какие проверки называть позитивными, а какие негативными.
Позитивное и негативное тестирование
Общепринятое определение звучит так:
Позитивные проверки— это проверки с данными, введения которых продукт ожидает от пользователя. Например, ожидает от нас система положительного числа в поле цена, мы вводим 100 руб.
Негативные проверки— это, соответственно, те данные, которых программа не ждет. В примере с ценой в негативном тестировании мы введем в это поле буквы, символы и т.п.
С тем, что мы подаем на вход системы, разобрались. Теперь нужно понять, какой результат ждем от выполнения проверок.
С позитивными кейсами ответ однозначный: ввели «хорошие» данные — получили результат “success”. А если вводим «плохие»? Здесь мы столкнулись с некоторой неоднозначностью. У негативных проверок может быть два результата:
- на данный ввод у системы есть ответ в виде сообщения/контроля;
- система не знает, как реагировать на введенные данные.
То есть у системы есть как минимум три реакции на наши действия по вводу данных:
- Действие: создание сущности, переход на новый шаг и т.п.
- Контроль: сообщение с контролем, блокировка дальнейших действий и т.п.
- Отказ: возникает исключение Exception, 404-ой ошибки и т.п.
Исходя из написанного выше, немного усложним формулировки и станем рассматривать определения «позитива» — «негатива» не только со стороны вводимых данных, но и со стороны полученного результата. В этом случае появится еще один тип проверок: условно-негативные. К условно-негативным будем относить все проверки, в которых при введении некорректных данных получаем успешный, с точки зрения логики, результат (сообщение об ошибке).
Теперь вернемся к тому вопросу, который был задан в самом начале: когда и какие негативные проверки стоит проводить?
Для себя я ввела некий условный «Жизненный цикл ПО в негативе». Его идея в том, что количество и тип негативных проверок будет зависеть от того, в какой стадии находится проект.
Проект пока еще как младенец. ЦА вроде бы изучена, аналитики написали первые варианты Технических Заданий (ТЗ), разработчики уже сделали первый вариант продукта и позвали нас тестировать.
Позитивное и Негативное тестирование. Positive vs Negative testing | Тестирование — Урок 9 | QA Labs
На этом этапе мы тестируем самый основной функционал и после прохождения базовых позитивных проверок большая часть наших тест-кейсов будет относиться к негативным и условно-негативным. Как показывает практика, именно на этом этапе большинство заводимых нами дефектов будет связано с отсутствием сообщения с контролем там, где оно должно быть.
На проекте исправлены все «детские болячки», учтены замечания с предыдущего уровня. В ТЗ, при необходимости, добавлены новые контроли. Проект стал похож на тинейджера — почти взрослый, все знает и умеет, но жизненного опыта недостаточно, чтобы справиться с нестандартными ситуациями. На этом этапе более внимательно тестируем позитивные состояния, проводя сложные проверки и применяя различные техники тест-дизайна. При этом уделяем не меньшее внимание и условно-негативным проверкам, ведь наша задача — убедиться, что на каждое действие есть реакция из п.1 или п.2, то есть не возникает отказов.
Проект готов! Он перешел с тестового стенда на прод, стабильно работает и живет взрослой жизнью. Все ошибки давно исправлены, а узкие места известны. На этом этапе мы чаще всего проводим регрессионное тестирование, используя в основном позитивные проверки.
Что касается негатива, то оптимальным для данного этапа будет проверка контролей (то есть условно-негативные кейсы) с помощью автотестов. Тем самым на этом этапе время, потраченное на ручное негативное тестирование, минимально и только в случае падения автотестов.
Вывод, который напрашивается из такого разделения, очевиден: чем более ранняя стадия разработки продукта, тем больше времени мы уделяем негативному тестированию. Если же мы имеем дело с давно функционирующим продуктом, без добавления новых фич, то негативное тестирование не будет особенно эффективным. Под проектом вовсе не обязательно понимать всю систему в целом, это правило с легкостью можно применять, например, и просто к новым функциональностям.
Конечно, на деле все не так просто, именно поэтому в начале статьи я сказала о том, что универсального правила когда, сколько и где проводить негативное тестирование — нет. Как нет однозначного ответа на вопрос, где заканчивается позитивное и начинается негативное тестирование, и что вообще понимать под этим процессом.
Например, куда отнести следующий кейс (все совпадения случайны и, наверняка, он был учтен “Амазоном”, но давайте пофантазируем): покупатель зашел в магазин Amazon Go за покупками, съел сэндвич на месте, вернул коробочку из-под него на место и вышел с пустыми руками, без оплаты покупки. С точки зрения линейного процесса и реализованного кода все отработало идеально.
С точки зрения бизнес-процесса — это явный fail. Задумались? Куда бы вы отнесли данный кейс? Может, у вас есть свои примеры, доказывающие, что в этом мире нет ничего однозначно черного или белого? Поделитесь в комментариях
03.2019
Последние новости
- Тестовая стратегия на пальцах: как перестать пропускать сроки сдачи проекта
- Секретный дайджест
- Проверьте себя: квиз на знание основ тестирования ПО
- Собеседования. Как отвечать на вопрос «Почему решили сменить работу?»
- Философия и цели тестирования ПО с точки зрения ISTQB FL
- Курсы по тестированию ПО: полное расписание на июнь 2023
- Гуманитарий ― это приговор? Можно ли стать тестировщиком, если ты «творческий»
Источник: qaschool.ru
РУКОВОДСТВО ПО НЕГАТИВНОМУ (ОТРИЦАТЕЛЬНОМУ) ТЕСТИРОВАНИЮ – ОБЪЯСНЕНИЕ НА ПРИМЕРАХ В РЕАЛЬНОМ ВРЕМЕНИ
В этой статье мы увидим, что такое отрицательное тестирование, на некоторых примерах сценариев отрицательного тестирования. Статья содержит следующие разделы:
Две основные стратегии тестирования в тестировании программного обеспечения: положительное тестирование и отрицательное тестирование.
Что такое отрицательное тестирование с примерами?
С точки зрения тестировщика программного обеспечения очень важно убедиться, что программное обеспечение выполняет свои основные функции в соответствии с требованиями, но не менее важно убедитесь, что программное обеспечение способно корректно справляться с любыми нештатными ситуациями или неправильным вводом, что помогает определить стабильность программного обеспечения. Отрицательное тестирование выполняется для выявления ситуаций, в которых существует вероятность сбоя программного обеспечения.
Это негативный подход, при котором тестировщики пытаются разработать тестовые примеры, чтобы найти негативные аспекты приложения и проверить его на неверный ввод. Отрицательное тестирование также известно как тестирование на отказ или тестирование путей ошибок. Функциональную надежность приложения можно измерить только с помощью разработанных отрицательных сценариев.
Примеры отрицательного тестирования (сценарии отрицательного тестирования):
Пример №1. Тестирование поля номера телефона.
Тестовые примеры для отрицательного тестирования могут включать ввод нечисловых значений или букв в поле номера телефона, проверку менее 10 символов или более 10 символов в поле номера телефона.
Пример 2. Тестирование поля возраста.
Тестовым примером для отрицательного тестирования может быть ввод возраста в виде алфавита или отрицательного целого числа.
Пример №3. Проверка поля почтового индекса.
Формат почтового индекса различается в разных странах. Отрицательными тестовыми примерами в таких сценариях могут быть введенные буквенно-цифровые значения для США, Индии и числовые для Канады и Великобритании. Превышение количества символов в поле почтового индекса также является отрицательным тестовым случаем.
Пример №4. Для обязательных полей
протестируйте, пропустив обязательный ввод данных, и попробуйте продолжить.
Пример №5. Для границ и ограничений данных
Введите большие значения, чтобы проверить размер полей.
Когда выполнять отрицательное тестирование Тестирование?
Отрицательное тестирование выполняется при функциональном тестировании сборки, где возможны непредвиденные условия. Его могут выполнить профессионалы.
Техники, используемые при положительном тестировании
Методы, используемые для отрицательного тестирования:
Анализ граничных значений:
Это связано с недопустимым разделом во входном диапазоне тестовых данных. . Система должна отклонить значения для недопустимых входных данных. Недопустимый раздел будет иметь 2 границы — нижнюю и верхнюю границу. Если диапазон входных тестовых данных — A-B, отрицательные тестовые случаи должны быть разработаны для A-1 и B+1.
Пример №1:Для поля даты (1–31) недопустимая нижняя граница раздела (введите 0 в поле даты) и недопустимая верхняя граница (введите 32 в поле даты) рассматриваются как отрицательные тестовые случаи.
Пример 2:Для полей имени пользователя, длина которых составляет 6-10 символов, недопустимая нижняя граница раздела (5 символов) и недопустимая верхняя граница раздела (11 символов) рассматриваются как отрицательные тестовые случаи.
Пример №3 :Для значений с плавающей запятой пусть система принимает значения от 0,2 до 0,8 с одним десятичным знаком. Недопустимая нижняя граница раздела (входное значение 0.1) и недопустимая верхняя граница (входное значение 0.9) учитываются для отрицательных тестовых случаев.
Подробнее о методе разработки тестового примера анализа граничных значений здесь
Разделение на эквивалентность:
В этом методе входные тестовые данные делятся на разделы. При отрицательном тестировании, если вы выберете значение из недопустимого раздела, система должна отклонить это значение.
Пример 1:Для полей даты (1-31) введите любое недопустимое значение, такое как 0 и отрицательные целые значения, система должна отклонить значения.
Пример № 2:Для полей имени пользователя, имеющих спецификации 6-10 символов, введите любое значение из недопустимого раздела, т. е. 0-5 или 11,12,13… и проверьте поведение системы. В этом случае система должна отклонить значения и отобразить ошибку.
Пример №3:Для полей Возраст от 18 до 80 лет, за исключением 60–65 лет, введите любое значение из недопустимого раздела, например 0–17, 60–65 или 81,82,83… и проверьте поведение системы.
Подробнее о Техника проектирования тестовых наборов эквивалентности здесь
В чем разница между положительным и отрицательным тестированием
Положительное тестирование и отрицательное тестирование
Выполняется путем передачи действительных тестовых данных
Выполняется путем передачи недопустимых тестовых данных
Выполняется для проверки известного набора тестовых условий
Выполняется для нарушения работы приложения с неизвестным набором тестовых условий
Охватывает только действительные случаи
Охватывает все возможные случаи, включая недействительные случаи
Это занимает меньше времени
Это занимает больше времени
Проверка выполнения всех требований
Проверка рабочих процессов, которые не выполняются упоминается в требованиях
Убедиться, что программное обеспечение работает должным образом
Источник: atesting.ru
Негативное тестирование – суть метода и его главные приемы
Основная цель тестирования — получить продукт оптимального качества. Тестеры пытаются выявить максимальное количество дефектов, тем самым гарантируя, что конечный пользователь не столкнется с отклонениями в работе приложения. Тестировщик стремится сделать тестирование эффективным, а эффективное тестирование подразумевает оптимизацию списка позитивных и негативных сценариев таким образом, чтобы добиться желаемого результата.
Позитивное тестирование
Позитивное тестирование помогает убедиться в том, что приложение функционирует должным образом и позволяет проверить, работает ли система в нормальных условиях так, как задумывалось. Но как понять, сможет ли система справиться с непредвиденными обстоятельствами?
Негативное тестирование
Негативное тестирование гарантирует, что приложение продолжит работу в случае ошибки или непредвиденного поведения со стороны пользователя. С его помощью можно определить, как система реагирует на неожиданности. Разработчики создают приложение в соответствии с заданными критериями приемлемости. Тестировщик знает, что обеспечивает нормальную работу функционала. Но он также обязан мыслить нестандартно, чтобы понять, что может привести к поломке приложения.
Например, если пользователь пытается ввести букву в поле для цифр, должно появится сообщение «Неверные данные, пожалуйста, введите цифры». Цель негативного тестирования — выявлять такие ситуации и предотвращать сбои в работе приложений, улучшая их качество. Негативное тестирование помогает как повысить качество работы приложения, так и найти его слабые места.
Негативное тестирование часто называют тестированием сбоев. Оно требует максимальной креативности, поскольку его предполагаемая цель — проверить, как отображаются ошибки и что при этом видит пользователь. Оно помогает оценить функциональную надежность приложения или программного обеспечения. Негативное тестирование направлено не только на выявление потенциальных недостатков, но и на определение условий, при которых приложение может выйти из строя.
В каких случаях требуется негативное тестирование? К примеру:
- Пользователь нажал кнопку «ОК», но не ввел данные.
- Введенные данные превышают допустимое количество знаков.
- Имя содержит числовые значения.
- В имени есть специальный символ, а приложение этого не предвидит.
- Использованы недопустимые слова.
Увидеть, как в вышеперечисленных случаях ведет себя программное обеспечение можно с помощью негативного тестирования.
Основные методы написания негативных тестов
Как определить максимальное количество негативных сценариев? Два наиболее широко используемых метода определения негативных сценариев тестирования включают:
— Анализ граничных значений;
Что такое «анализ граничных значений»?
Анализ граничных значений — это процесс тестирования между крайними точками или границами входных значений. Крайние значения (например, Start-End, Lower-Upper, Maximum-Minimum, Just Inside-Just Outside) называются граничными, а тестирование называется «анализом граничных значений». Основная идея этого подхода состоит в следующем — нужно выбрать значения входных переменных на их:
- Минимуме;
- Чуть выше минимума;
- Номинальном значении;
- Чуть ниже максимума;
- Максимуме.
Что такое «разделение эквивалентности»?
Входные данные домена делятся на разные классы эквивалентности. Этот метод позволяет взять все возможные тесты и поместить их в классы. Во время тестирования из каждого класса выбирается одно тестовое значение. Если вы тестируете поле ввода, куда можно вводить числа от 1 до 1000, нет смысла писать тысячи тестов для всех действительных входных чисел. Тесты можно разделить на классы согласно трем наборам входных данных.
- Класс входных данных для всех допустимых входных данных.
- Класс входных данных со всеми значениями за нижним пределом.
- Входные данные с любым значением больше 1000.
Проблемы негативного тестирования
Не все тестировщики охотно занимаются негативным тестированием, поскольку считают, что это пустая трата времени и энергии и может потенциально отсрочить релиз программного обеспечения. Позитивное тестирование, как правило, получает достаточное внимание, а вот негативное – нет. Нельзя упускать его из виду, поскольку именно оно гарантирует, что система справится с неожиданными условиями работы. Позитивное тестирование, безусловно, играет важнейшую роль, ведь именно оно показывает, решает ли приложение те задачи, ради которых оно и разрабатывалось. Но бесперебойная работа невозможна без негативного тестирования.
Негативное тестирование в действии
Представим следующую ситуацию — у вас есть экран входа в приложение с двумя текстовыми полями. В первое текстовое поле необходимо ввести имя пользователя. Во второе — пароль. К вводу данных есть конкретные требования. К примеру, имя пользователя в первом поле не может состоять только из символов.
Кроме того, оно не может оставаться пустым (это же требование распространяется и на второе текстовое поле). Пароль может включать любую комбинацию букв (заглавных или строчных) или цифр от 0 до 9. Использовать другие символы нельзя. Максимальное количество символов для обоих полей — 10.
Как, в таком случае, выглядит негативное тестирование?
- Попробуйте ввести имя пользователя, состоящее из цифр и символов или только символов: 123 * _ ;
- Создайте пароль, включающий специальные символы и пробелы:
- Оставьте оба поля пустыми;
- Введите более 10 символов в оба текстовых поля.
Наша цель – посмотреть, как приложение реагирует на непредвиденное поведение и нестандартные ситуации. Для этого нужно испробовать различные сценарии. Написание негативных тестов — процесс, требующий креативного подхода и творческого мышления. По сути, вам необходимо представить, как можно «сломать» приложение и попытаться это сделать. Можно отталкиваться от требований и идти им наперекор, но лучше не делать этого напрямую, поскольку тогда существует риск, что проведенное вами тестирование окажется позитивным, а не негативным.
Негативное тестирование — это уникальный тип тестирования. Основная часть тестов нацелена на проверку и подтверждение соответствия системы заданным требованиям. Этот же тип тестирования, напротив, работает с тем, что система делать не должна. Отрицательный тест выходит за рамки требований. Его главный фокус — неожиданные сценарии, поэтому важно мыслить нестандартно.
Андрей Мельничук
Автор. Пишет о компьютерной технике, электронике и ИТ, делает аналитические обзоры.
Источник: www.careerist.com