Что такое негативное тестирование
Тестировщик «с нуля»
Страницы
1 апреля 2011 г.
“Негативное” и “позитивное” тестирование
“Позитивное” тестирование – это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению системы.
Основной целью “позитивного” тестирования является проверка того, что при помощи системы можно делать то, для чего она создавалась.
“Негативное” тестирование – это тестирование на данных или сценариях, которые соответствуют нештатному поведению тестируемой системы – различные сообщения об ошибках, исключительные ситуации, “запредельные” состояния и т.п.
Основной целью “негативного” тестирования является проверка устойчивости системы к воздействиям различного рода, валидация неверного набора данных, проверка обработки исключительных ситуаций (как в реализации самих программных алгоритмов, так и в логике бизнес-правил).
Однако предшествовать “позитивному” и “негативному” тестированию должны работы по выполнению “дымового” тестирования.
Почему “позитивное” тестирование считается на порядок более важным, чем “негативное”?
Предположим, что система не слишком устойчива к “плохим” вводимым данным. Это страшно? Зачастую не слишком. Пользователи рано или поздно научатся обходить “подводные камни”, не будут делать “опасные” или “неразрешенные” действия, служба технической поддержки скоро запомнит, какие проблемы обычно возникают у пользователей и будет давать советы типа “ни в коем случае не оставляйте это поле пустым, а то…”.
НО – всего этого не будет вовсе, если система не выполняет свое основное предназначение, если пользователи (заказчики) не могут решить свои бизнес задачи, если они все делают правильно, вводят хорошие данные, но не получают результата. И посоветовать им ничего в этой ситуации нельзя.
Именно поэтому “позитивное” тестирование гораздо, гораздо важнее “негативного”.
Ошибки в нормальном поведении, мешающие пользователям выполнять бизнес задачи обходятся в разы дороже, чем редкие падения системы, связанные с тем, что кто-то ввел некорректные данные.
Впрочем, это не означает, что “негативными” тестами можно пренебречь, т.к. не на всех этапах жизненного цикла ПО приоритеты ценностей сохраняются неизменными.
Негативное тестирование зачастую позволяет найти большее количество ошибок, но это становится важным только когда все положительные тесты уже сделаны.
Что такое негативное тестирование
Если вдруг вам лень читать, то у нас есть еще и видео на эту тему 🙂 https://youtu.be/JOCqwgRO_JQ
Представьте, что перед вами стоит задача проверки поля в форме. С чего начнете? Наверняка найдутся те, кто бросится ломать форму и вводить некорректные данные. Но большинство упомянет о необходимости проведения сначала позитивных проверок, ведь прежде необходимо убедиться, что поле в принципе способно обрабатываться. И уже потом вы перейдете к негативным. И будете правы. Но только в теории. 🙂
На практике же не существует проектов, в которых нужно тестировать со всех сторон единственное поле. Таких полей может быть тысячи и сроки дедлайна (в нашем мире, где они обычно обозначены как «вчера») порой не позволяют провести полностью даже позитивные проверки, не говоря о негативных.
Как быть? Какой приоритет должен быть у негативных проверок? А, может, не проверять негатив вообще? Как это часто бывает, универсального ответа нет, но я постараюсь рассказать о том, как тестирую сама. 🙂
Для начала давайте разберемся с терминами. Какие проверки называть позитивными, а какие негативными.
Общепринятое определение звучит так:
Позитивные проверки — это проверки с данными, введения которых продукт ожидает от пользователя. Например, ожидает от нас система положительного числа в поле цена, мы вводим 100 руб.
Негативные проверки — это, соответственно, те данные, которых программа не ждет. В примере с ценой в негативном тестировании мы введем в это поле буквы, символы и т.п.
С тем, что мы подаем на вход системы, разобрались. Теперь нужно понять, какой результат ждем от выполнения проверок.
С позитивными кейсами ответ однозначный: ввели «хорошие» данные — получили результат “success”. А если вводим «плохие»? Здесь мы столкнулись с некоторой неоднозначностью. У негативных проверок может быть два результата:
То есть у системы есть как минимум три реакции на наши действия по вводу данных:
Исходя из написанного выше, немного усложним формулировки и станем рассматривать определения «позитива» — «негатива» не только со стороны вводимых данных, но и со стороны полученного результата. В этом случае появится еще один тип проверок: условно-негативные. К условно-негативным будем относить все проверки, в которых при введении некорректных данных получаем успешный, с точки зрения логики, результат (сообщение об ошибке).
Теперь вернемся к тому вопросу, который был задан в самом начале: когда и какие негативные проверки стоит проводить?
Для себя я ввела некий условный «Жизненный цикл ПО в негативе». Его идея в том, что количество и тип негативных проверок будет зависеть от того, в какой стадии находится проект.
Проект пока еще как младенец. ЦА вроде бы изучена, аналитики написали первые варианты Технических Заданий (ТЗ), разработчики уже сделали первый вариант продукта и позвали нас тестировать.
На этом этапе мы тестируем самый основной функционал и после прохождения базовых позитивных проверок большая часть наших тест-кейсов будет относиться к негативным и условно-негативным. Как показывает практика, именно на этом этапе большинство заводимых нами дефектов будет связано с отсутствием сообщения с контролем там, где оно должно быть.
На проекте исправлены все «детские болячки», учтены замечания с предыдущего уровня. В ТЗ, при необходимости, добавлены новые контроли. Проект стал похож на тинейджера — почти взрослый, все знает и умеет, но жизненного опыта недостаточно, чтобы справиться с нестандартными ситуациями. На этом этапе более внимательно тестируем позитивные состояния, проводя сложные проверки и применяя различные техники тест-дизайна. При этом уделяем не меньшее внимание и условно-негативным проверкам, ведь наша задача — убедиться, что на каждое действие есть реакция из п.1 или п.2, то есть не возникает отказов.
Проект готов! Он перешел с тестового стенда на прод, стабильно работает и живет взрослой жизнью. Все ошибки давно исправлены, а узкие места известны. На этом этапе мы чаще всего проводим регрессионное тестирование, используя в основном позитивные проверки. Что касается негатива, то оптимальным для данного этапа будет проверка контролей (то есть условно-негативные кейсы) с помощью автотестов. Тем самым на этом этапе время, потраченное на ручное негативное тестирование, минимально и только в случае падения автотестов.
Вывод, который напрашивается из такого разделения, очевиден: чем более ранняя стадия разработки продукта, тем больше времени мы уделяем негативному тестированию. Если же мы имеем дело с давно функционирующим продуктом, без добавления новых фич, то негативное тестирование не будет особенно эффективным. Под проектом вовсе не обязательно понимать всю систему в целом, это правило с легкостью можно применять, например, и просто к новым функциональностям.
Конечно, на деле все не так просто, именно поэтому в начале статьи я сказала о том, что универсального правила когда, сколько и где проводить негативное тестирование — нет. Как нет однозначного ответа на вопрос, где заканчивается позитивное и начинается негативное тестирование, и что вообще понимать под этим процессом.
Например, куда отнести следующий кейс (все совпадения случайны и, наверняка, он был учтен “Амазоном”, но давайте пофантазируем): покупатель зашел в магазин Amazon Go за покупками, съел сэндвич на месте, вернул коробочку из-под него на место и вышел с пустыми руками, без оплаты покупки. С точки зрения линейного процесса и реализованного кода все отработало идеально. С точки зрения бизнес-процесса — это явный fail. Задумались? Куда бы вы отнесли данный кейс? Может, у вас есть свои примеры, доказывающие, что в этом мире нет ничего однозначно черного или белого? Поделитесь в комментариях 😉
Позитивный взгляд на негативное тестирование
Известный факт, что компании по тестированию очень обеспокоены качеством продуктов. Это объясняет всемирную доступность тестировщиков программного обеспечения. Предоставляя услуги тестирования ПО, эти люди обеспечивают его качество.
Многие тестировщики никогда не забудут о негативном тестировании, хотя не все программисты этим довольны. Такой контроль нужен для защиты от хакеров, ботов, Dos/DDos атак.
Каково призвание специалистов по тестированию? Они должны найти проблемы, которые не видны другим. Не затягивайте с негативным тестированием, иначе вы подвергаете систему опасности.
Позитивное и негативное тестирование
Давайте начнем с самого начала. Есть 2 вида контроля, когда тест-кейсы включены в тестирование: позитивный и негативный. Преимущество у последнего.
Позитивное тестирование – это процесс проверки на корректное поведение согласно техническим требованиям и документации. Позитивное тестирование выполняется для обеспечения того, что система делает именно то, что ожидается.
Негативное тестирование – это процесс проверки на некорректное поведение. В ходе такого тестирования мы можем узнать, что система справится с непредвиденными ситуациями.
Позитивно-негативное тестирование
Чтобы выполнять тестирование программного обеспечения, нужно обладать интуицией либо охотничьим инстинктом. Специалист по тестированию – это разносторонний человек, который может выполнять и бизнес анализ, и тестирование.
Тестировщики проверяют, корректно ли выполняется процесс: есть ли соответствие с техническими требованиями и тестовыми сценариями. Проведение позитивного и негативного тестирования отдельно займет больше времени, чем их одновременное выполнение. Это потому что есть две тестовые итерации.
В конце концов, чем ближе час Х, тем быстрее идет время и тем скорее нужно выполнять задачи, исправлять дефекты, применять бизнес-требования (которые могут варьироваться) и сделать еще много дел. Дедлайн – это самое жаркое время!
Разделение негативного и позитивного тестирования просто противоречит природе тестировщика! Его задача – проверить систему на все возможные действия конечного пользователя.
Люди в основном нелогичны и могут спровоцировать проблемы в программном обеспечении. Негативное тестирование поможет избежать возникновения проблем.
понедельник, 10 февраля 2014 г.
Позитивное и негативное тестирование
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
36 комментариев:
Две из трех основных парадигм расписаны, это хорошо )
Впринципе, можно было бы уложиться в несколько строчек.
1. Тестирование на позитивных значениях.
Обычно используются пользовательские сценарии с корректными значениями.
Проверяем работоспособность заявленного функционала.
3. Тестирование в невозможных конфигурациях.
Своеобразный эд-хок. Проверка того, что система правильно обрабатывает нештатные ситуации и эксепшны.
Впринципе, две последних парадигмы некоторые объединяют в одну, но я бы не стал этого делать.
Да, Андрей, спасибо 🙂
Согласна, что негативные тесты можно разделить на простые ошибки и эксепшены. Это хороший подход 🙂
Кстати, чем отличается тест-дизайнер от проектировщика тестов?
И часто ли приходят люди, проработавшие несколько лет, но не знающие разделения на негативное и позитивное тестирование и претендующие на позиции тест-дизайнера?
Я согласен, что базовые негативные тесты (вроде корня из отрицательного числа, хотя это внезапно может оказаться и позитивным тестом, если вспомнить, что существует мнимая единица :)) стоит прогнать где-то в серединке. И необходимо уметь придумывать негативные тесты. Но прежде чем начинать тестировать квадратные корни из иврита хорошо бы подумать, какие позитивные кейсы были пропущены в базовом наборе.
Да, ты прав, пожалуй, стоит просить дать полный комплект, а не несколько тестов 🙂
Хотя все, что ты тут нафлудил, мы проходим, просто немного дальше, на уроке по классам эквивалентности 🙂 А первые лекции вводные, так, просто чтобы понять, какие виды тестирования вообще существуют ))
Топ-10 негативных тест-кейсов, используемых во время тестирования ПО
С помощью негативных тест-кейсов выполняются проверки на уровень функциональности программного обеспечения при условии использования негативных данных. Подобные тест-кейсы необходимо выполнять при проверке любого ПО.
Далее будут приведены 10 самых используемых негативных тестовых сценариев, которые должны применяться на постоянной основе.
1. Внутренние одинарные кавычки (Embedded Single Quote)
В большей части базы данных SQL могут возникать некоторые проблемы с наличием одинарных кавычек в теле запроса (к примеру, Ritchie’s car).
Всегда применяйте одинарные кавычки при валидации каждого поля ввода, функционирующего с БД.
2. Обязательный ввод данных (Required Data Entry)
В любой спецификации на продукт всегда необходимо указывать все поля, где требуется в обязательном порядке вводить данные. Помните о том, что все формы, которые содержат цифирные или текстовые поля, определенные как «обязательные», не сохраняются при полном отсутствии информации в них.
3. Виды данных полей (Fields Type test)
Спецификации для ПО должны содержать типы данных, определенные для каждого конкретного поля (поле даты, времени, числовые поля, поля для контактных телефонов, поле для email и прочее). Всегда нужно проверять любое текстовое поле на его возможность свободно вводить / выводить (и сохранять) из спецификации исключительно определенный вид информации (к примеру, программа должна отображать запрет на введение пользователем букв или специальных символов, если данное поле числовое).
4. Размеры полей (Fields Size Test)
Информационные критерии соответствия ПО заявленным требованиям должны валидировать только четко установленному максимальному набору знаков в каждом поле. К примеру, сумма знаков в поле с именем пользователя должна быть не более 50 знаков. Нужно тестировать, что программа запрещает пользователю вводить или сохранять в системе большее количество знаков, нежели указанно в содержании спецификаций.
Всегда помните о том, что информация любого поля должна не просто корректно валидироваться, но и иметь возможность сообщать пользователю об установленных ограничениях. Например, оповещения на основе использования пояснительных текстовых блоков или всплывающих окон с ошибками.
5. Проверка числовых ограничений (Numeric Bounds Test)
Некоторые числовые поля ПО могут содержать определенные ограничения на ввод допустимых числовых комбинаций. Подобные ограничения могут находиться в спецификации продукта или происходить из логики его работы.
К примеру, перед вами поставлена задача по проверке функциональности, которая касается начисления процентов на счет. В таком случае, тест-кейс должен быть нацелен на проверку возможности начисленных процентов нести в себе отрицательные индексы (то есть, такое возможно или нет).
Всегда стоит тестировать ПО на выдачу ошибки в ситуации, когда значения находятся за границами валидного диапазона данных. Как пример, информация об ошибке должна отображаться при вводе данных 19 и 26 при возможном значении от 20 до 25.
6. Числовые ограничения (Numeric Limits Test)
Существует большое количество БД и языков программирования, которые определяют числовые значения в форме переменных с некоторым видом.
Крайне важно тестировать граничные данные применяемых в БД переменных для числовых полей, граничные показатели которых не четко выделены и расписаны в содержании спецификации.
7. Гранично-допустимые значения даты (Date Bounds Test)
Есть программы, которые содержат логические ограничения для полей, демонстрирующих время и дату. К примеру, если проверяющий тестирует поле даты рождения пользователя, правильным будет выполнить проверку на возможность ввода будущей даты (то есть такой, которая физически еще не наступила). Также стоит проверить ограничение на ввод даты, разнящейся от необходимой более чем на 150 лет.
8. Валидная дата (Date Validity)
Поле даты обязательно должно содержать запрограммированную проверку ввода валидных значений. И всегда стоит помнить о надобности тестирования даты в високосный год.
9. Веб-сессии (Web Session Testing)
Множество веб-программ основаны на работе браузерных сессий и направлены на отслеживание пользователей, вошедших в систему. При этом они дополнительно применяют массу специфических конфигураций для определенного виртуального пользователя.
Кроме того, некоторые функциональные возможности ПО не могут и не должны работать без шага предварительного логирования в системе. Нужно тестировать ПО на то, что страницы или логика работы ПО после логирования абсолютно недоступны пользователям, которые не прошли процесс верификации в системе.
10. Настройки производительности (Performance Changes)
Все новые версии программного обеспечения должны внедряться в использование только после стадии тестирования их производительности (скорость добавления данных, процесс удаления информации и прочее).
Сравнивайте итоги с тестами производительности ранних модификаций продукта. Такая стратегия тестирования позволяет изначально находить возможные проблемы производительности, которые могут возникнуть вследствие редактирования программного кода в новых версиях ПО.