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

Если вдруг вам лень читать, то у нас есть еще и видео на эту тему 🙂 https://youtu.be/JOCqwgRO_JQ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I этап.
NEWBORN

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

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

II этап.
TEENAGER


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

III этап.
ADULT


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

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

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

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

Метки
Android (1)courses (1)HR (1)iOS (1)java (1)kaizen (2)QA (7)QualityLab (1)selenium (1)softwaretesting (1)sql (4)TestSuites (1)usability (2)БАГИ (1)Исследовательское тестирование (2)Истории поинт (6)Курс тестирования для начинающих (1)Мнемоники (1)Мнемоники в тестировании (1)Нина Агеева (4)ПОИНТ (26)ПРомо-вебинар (1)Роман Буданов (3)Скриншот (1)Тестирование (9)Тестирование ПО (1)Тренер (11)Туры (1)автоматизация (2)алгоритмы (1)баг (1)безопасность (1)введение в тестирование (1)домашки (1)займемсяпоинтом (1)игры (1)идеальный мир (1)интернет (1)истории выпускников (6)как надо тестировать (2)конференция (1)котик (1)курс для начинающих тестировщиков онлайн (1)мобилки (2)мобильное тестирование (2)настройка мозгов (1)начинающий тестировщик (4)негативное тестирование (2)организация тестирования (1)персонажи (1)планирование (1)постановка мозгов (2)работа над ошибками (1)рабочий процесс (1)радиоСаня (1)режим разработчика (2)резюме (1)сопроводительное письмо (1)тайм-менеджмент (1)тестировани (1)тестирование usability (2)тестирование безопасности (1)тестирование мобильных приложений (1)тестировщик (4)улучшайзинг (1)ученик (2)фреймворки (1)чит лист (1)что должен делать тестировщик (1)
С 15.07 по 9.09, ОНЛАЙН Зарегистрироваться