negative testing что это
говориМ о тестировании
простым языком
Виды тестирования по позитивности сценария
Позитивное тестирование – это тестирование с применением сценариев, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. С его помощью мы можем определить, что система делает то, для чего и была создана.
Негативным называют тестирование, в рамках которого применяются сценарии, которые соответствуют внештатному поведению тестируемой системы. Это могут быть исключительные ситуации или неверные данные.
Прежде всего негативное тестирование направлено на проверку устойчивости системы к различным воздействиям, валидации неверных данных, обработку исключительных ситуаций. Сценарии позитивного тестирования, в свою очередь, направлены на проверку работы системы с теми типами данных для которых, она разрабатывалась.
Реакция продукта на тесты
Какой результат мы ждем от позитивных и негативных тестов?
Позитивное тестирование должно нам всегда давать результат в виде отсутствия багов.
Негативные проверки могут дать 2 результата:
1. На данный ввод у продукта есть ответ в виде сообщения/контроля.
2. Система не знает, как реагировать на введенные данные.
Получается, есть три реакции на действия по вводу данных:
— Действие: создание сущности, переход на новый шаг и т.п.
— Контроль: сообщение с контролем, блокировка дальнейших действий и т.п.
— Отказ: возникает исключение Exception, 404-ой ошибки и т.п.
Для чего важно различать?
Для чего нам различать негативное и позитивное тестирование? Чтобы верно расставлять приоритеты в тестировании в зависимости от ситуации.
Создание позитивных сценариев (тест-кейсов), как правило, предшествует созданию негативных.
Сначала мы проверяем работу системы, когда наш условный пользователь работает с системой «правильно». А уже потом приступаем к проверке отклика системы на пользователя, который допускает различные ошибки (ввод неверных данных, например). И наша система должна быть готова ответить на неверный запрос. Это и есть цель негативного тестирования.
Почему важно сначала провести позитивное тестирование? Большинство пользователей использует наш продукт так, как необходимо. То есть, если в поле ввода просят указать «Имя», то большинство пользователей напишут в него именно имя, а не набор цифр. Если мы не проверим верно ли распознаются корректные данные, то в случае ошибки большинство пользователей не смогут воспользоваться нашим продуктом.
Именно поэтому мы делим все тесты на позитивные и негативные и начинаем тестировать с позитивных. Именно с позитивных, так как они приоритетней. Лучше не останется времени на негативные тесты, чем мы не проверим основной функционал продукта на способность корректно отвечать пользователю на корректные запросы.
Пример позитивных и негативных тестов
Давайте рассмотрим эти виды тестирования немного подробнее на примере формы авторизации на сайте.
С помощью позитивных тестов мы проверим, что наша форма регистрации работает верно. Для этого проведем следующие тесты:
К негативным тестам можно отнести следующие сценарии:
Повторюсь, при тестировании очень важно соблюдать приоритет.
Сначала мы выполняем позитивные тесты, а потом негативные.
Это связано с тем, что для продукта и пользователей важно, чтобы все фичи работали правильно, так как задумывались изначально.
К примеру, ошибка при авторизации с правильным логином и паролем гораздо опаснее, чем проблема возникающая, когда пользователь вводит неправильный пароль. А критичные ошибки лучше всегда находить как можно раньше, чтобы было время их исправить и внимательно проверить.
Negative testing что это
Если вдруг вам лень читать, то у нас есть еще и видео на эту тему 🙂 https://youtu.be/JOCqwgRO_JQ
Представьте, что перед вами стоит задача проверки поля в форме. С чего начнете? Наверняка найдутся те, кто бросится ломать форму и вводить некорректные данные. Но большинство упомянет о необходимости проведения сначала позитивных проверок, ведь прежде необходимо убедиться, что поле в принципе способно обрабатываться. И уже потом вы перейдете к негативным. И будете правы. Но только в теории. 🙂
На практике же не существует проектов, в которых нужно тестировать со всех сторон единственное поле. Таких полей может быть тысячи и сроки дедлайна (в нашем мире, где они обычно обозначены как «вчера») порой не позволяют провести полностью даже позитивные проверки, не говоря о негативных.
Как быть? Какой приоритет должен быть у негативных проверок? А, может, не проверять негатив вообще? Как это часто бывает, универсального ответа нет, но я постараюсь рассказать о том, как тестирую сама. 🙂
Для начала давайте разберемся с терминами. Какие проверки называть позитивными, а какие негативными.
Общепринятое определение звучит так:
Позитивные проверки — это проверки с данными, введения которых продукт ожидает от пользователя. Например, ожидает от нас система положительного числа в поле цена, мы вводим 100 руб.
Негативные проверки — это, соответственно, те данные, которых программа не ждет. В примере с ценой в негативном тестировании мы введем в это поле буквы, символы и т.п.
С тем, что мы подаем на вход системы, разобрались. Теперь нужно понять, какой результат ждем от выполнения проверок.
С позитивными кейсами ответ однозначный: ввели «хорошие» данные — получили результат “success”. А если вводим «плохие»? Здесь мы столкнулись с некоторой неоднозначностью. У негативных проверок может быть два результата:
То есть у системы есть как минимум три реакции на наши действия по вводу данных:
Исходя из написанного выше, немного усложним формулировки и станем рассматривать определения «позитива» — «негатива» не только со стороны вводимых данных, но и со стороны полученного результата. В этом случае появится еще один тип проверок: условно-негативные. К условно-негативным будем относить все проверки, в которых при введении некорректных данных получаем успешный, с точки зрения логики, результат (сообщение об ошибке).
Теперь вернемся к тому вопросу, который был задан в самом начале: когда и какие негативные проверки стоит проводить?
Для себя я ввела некий условный «Жизненный цикл ПО в негативе». Его идея в том, что количество и тип негативных проверок будет зависеть от того, в какой стадии находится проект.
Проект пока еще как младенец. ЦА вроде бы изучена, аналитики написали первые варианты Технических Заданий (ТЗ), разработчики уже сделали первый вариант продукта и позвали нас тестировать.
На этом этапе мы тестируем самый основной функционал и после прохождения базовых позитивных проверок большая часть наших тест-кейсов будет относиться к негативным и условно-негативным. Как показывает практика, именно на этом этапе большинство заводимых нами дефектов будет связано с отсутствием сообщения с контролем там, где оно должно быть.
На проекте исправлены все «детские болячки», учтены замечания с предыдущего уровня. В ТЗ, при необходимости, добавлены новые контроли. Проект стал похож на тинейджера — почти взрослый, все знает и умеет, но жизненного опыта недостаточно, чтобы справиться с нестандартными ситуациями. На этом этапе более внимательно тестируем позитивные состояния, проводя сложные проверки и применяя различные техники тест-дизайна. При этом уделяем не меньшее внимание и условно-негативным проверкам, ведь наша задача — убедиться, что на каждое действие есть реакция из п.1 или п.2, то есть не возникает отказов.
Проект готов! Он перешел с тестового стенда на прод, стабильно работает и живет взрослой жизнью. Все ошибки давно исправлены, а узкие места известны. На этом этапе мы чаще всего проводим регрессионное тестирование, используя в основном позитивные проверки. Что касается негатива, то оптимальным для данного этапа будет проверка контролей (то есть условно-негативные кейсы) с помощью автотестов. Тем самым на этом этапе время, потраченное на ручное негативное тестирование, минимально и только в случае падения автотестов.
Вывод, который напрашивается из такого разделения, очевиден: чем более ранняя стадия разработки продукта, тем больше времени мы уделяем негативному тестированию. Если же мы имеем дело с давно функционирующим продуктом, без добавления новых фич, то негативное тестирование не будет особенно эффективным. Под проектом вовсе не обязательно понимать всю систему в целом, это правило с легкостью можно применять, например, и просто к новым функциональностям.
Конечно, на деле все не так просто, именно поэтому в начале статьи я сказала о том, что универсального правила когда, сколько и где проводить негативное тестирование — нет. Как нет однозначного ответа на вопрос, где заканчивается позитивное и начинается негативное тестирование, и что вообще понимать под этим процессом.
Например, куда отнести следующий кейс (все совпадения случайны и, наверняка, он был учтен “Амазоном”, но давайте пофантазируем): покупатель зашел в магазин Amazon Go за покупками, съел сэндвич на месте, вернул коробочку из-под него на место и вышел с пустыми руками, без оплаты покупки. С точки зрения линейного процесса и реализованного кода все отработало идеально. С точки зрения бизнес-процесса — это явный fail. Задумались? Куда бы вы отнесли данный кейс? Может, у вас есть свои примеры, доказывающие, что в этом мире нет ничего однозначно черного или белого? Поделитесь в комментариях 😉
Creative work
Терминология Quality assurance
Позитивное тестирование (positive testing)
Это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. Основной целью “позитивного” тестирования является проверка того, что при помощи системы можно делать то, для чего она создавалась.
Негативное тестирование (negative testing)
Это тестирование на данных или сценариях, которые соответствуют нештатному поведению. Основной целью “негативного” тестирования является проверка устойчивости системы к воздействиям различного рода, валидация неверного набора данных.
Функциональное тестирование (functional testing)
Это тестирование в целях проверки реализуемости функциональных требований для решения задачи пользователя.
Функциональные тестирование включают в себя:
Тестирование производительности (performance testing)
Это тестирование, которое проводится с целью определения, как быстро работает вычислительная система или её часть под определённой нагрузкой. Также может служить для проверки и подтверждения других атрибутов качества системы, таких как масштабируемость, надёжность и потребление ресурсов.
Тестирование производительности включают в себя:
Тестирование удобства использования (usability testing)
Это тестирование удобство использования определяет степень простоты доступа пользователя к функциям системы, предоставляемым через пользовательский интерфейс.
Тестирование пользовательского интерфейса (UI testing)
Тестирование графического интерфейса пользователя предполагает проверку соответствия приложения требованиям к графическому интерфейсу, профессионально ли оно выглядит, выполнено ли оно в едином стиле.
Тестирование безопасности (security testing)
Процесс оценки уязвимости программного обеспечения к различным атакам.
Тестирование локализации (localization testing)
Это процесс тестирования локализованной версии программного продукта. Проверка правильности перевода элементов интерфейса пользователя, проверка правильности перевода системных сообщений и ошибок, проверка перевода раздела “Помощь”/“Справка” и сопроводительной документации.
Тестирование совместимости (compatibility testing)
Вид нефункционального тестирования, основной целью которого является проверка корректной работы продукта в определенном окружении.
Окружение может включать в себя следующие элементы:
Тестирование чёрного ящика (black box)
Метод тестирования функционального поведения объекта (программы, системы) с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве тестируемого объекта.
Тестирование белого ящика (white box)
Выполняется с целью обнаружения проблем во внутренней структуре программы. Это требует от проверяющего глубокого знания внутренней структуры и следовательно, не может быть выполнено обычным пользователем. Общая задача такого тестирования обеспечить проверку каждого шага по алгоритму программы.
Тестирование серого ящика (grey box)
Представляет собой сочетание тестирования белого ящика и черного ящика. Целью данного тестирования является поиск дефектов, если таковые из-за неправильного структуры или неправильного использования приложений.
Ручное тестирование (manual testing)
Это процесс поиска дефектов в работе программы, когда происходит тестирования работоспособность всех компонентов программы, как если бы он был пользователем.
Автоматизированное тестирование (automated testing)
Этот процесса тестирования использует программные средства для выполнения тестов и проверки результатов выполнения, что помогает сократить время тестирования и упростить его процесс.
Модульное тестирование (component/unit testing)
Процесс позволяющий проверить на корректность отдельные модули исходного кода программы.
Интеграционное тестирование (integration testing)
Тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. Интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.
Системное тестирование (system/end-to-end testing)
Это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования чёрного ящика и тем самым, не требует знаний о внутреннем устройстве системы.
Мы рассмотрели лишь небольшую часть терминологии, но достаточно важную в QA. Возможно, мы еще затронем тему тестирования, а на сегодня это все.
Похожие статьи:
Тестировщик «с нуля»
Страницы
1 апреля 2011 г.
“Негативное” и “позитивное” тестирование
“Позитивное” тестирование – это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению системы.
Основной целью “позитивного” тестирования является проверка того, что при помощи системы можно делать то, для чего она создавалась.
“Негативное” тестирование – это тестирование на данных или сценариях, которые соответствуют нештатному поведению тестируемой системы – различные сообщения об ошибках, исключительные ситуации, “запредельные” состояния и т.п.
Основной целью “негативного” тестирования является проверка устойчивости системы к воздействиям различного рода, валидация неверного набора данных, проверка обработки исключительных ситуаций (как в реализации самих программных алгоритмов, так и в логике бизнес-правил).
Однако предшествовать “позитивному” и “негативному” тестированию должны работы по выполнению “дымового” тестирования.
Почему “позитивное” тестирование считается на порядок более важным, чем “негативное”?
Предположим, что система не слишком устойчива к “плохим” вводимым данным. Это страшно? Зачастую не слишком. Пользователи рано или поздно научатся обходить “подводные камни”, не будут делать “опасные” или “неразрешенные” действия, служба технической поддержки скоро запомнит, какие проблемы обычно возникают у пользователей и будет давать советы типа “ни в коем случае не оставляйте это поле пустым, а то…”.
НО – всего этого не будет вовсе, если система не выполняет свое основное предназначение, если пользователи (заказчики) не могут решить свои бизнес задачи, если они все делают правильно, вводят хорошие данные, но не получают результата. И посоветовать им ничего в этой ситуации нельзя.
Именно поэтому “позитивное” тестирование гораздо, гораздо важнее “негативного”.
Ошибки в нормальном поведении, мешающие пользователям выполнять бизнес задачи обходятся в разы дороже, чем редкие падения системы, связанные с тем, что кто-то ввел некорректные данные.
Впрочем, это не означает, что “негативными” тестами можно пренебречь, т.к. не на всех этапах жизненного цикла ПО приоритеты ценностей сохраняются неизменными.
Негативное тестирование зачастую позволяет найти большее количество ошибок, но это становится важным только когда все положительные тесты уже сделаны.
Позитивне та негативне тестування
Позитивне та негативне тестування
Сьогодні як ніколи актуальним є питання тестування програмного забезпечення. І актуальність даної послуги полягає перш за все в щоденній необхідності аналізу різних систем і їх компонентів. Як наслідок, існує цілий ряд видів тестування. Нижче нами буде розглянута одна з класифікацій тестування за ознакою позитивності сценаріїв.
Позитивне тестування – це тестування із застосуванням сценаріїв, які відповідають нормальній (штатній, очікуваній) поведінці системи. З його допомогою ми можемо визначити, що система робить те, для чого і була створена. Наприклад, множення на калькуляторі цифр 3 і 5.
Негативним називають тестування, в рамках якого застосовуються сценарії, які відповідають позаштатній поведінці тестованої системи. Це можуть бути, наприклад, виняткові ситуації або невірні дані. На прикладі калькулятора, це множення числа 3 на грушу. Значення «груша» не є дійсним для калькулятора.
Перш за все негативне тестування направлено на перевірку стійкості системи до різних впливів, валідації невірних даних, обробки виняткових ситуацій. Сценарії позитивного тестування, в свою чергу, спрямовані на перевірку роботи системи з тими типами даних, для яких вона розроблялася.
Створення позитивних сценаріїв (тест-кейсів), як правило, передує створенню негативних тест-кейсів. Спочатку ми перевіряємо роботу системи, коли наш умовний користувач працює з системою «правильно», а потім приступаємо до перевірки відгуку системи на користувача, який допускає різні помилки (введення невірних даних, наприклад). І наша система повинна бути готова відповісти на невірний запит. Це і є мета негативного тестування.
Сьогодні немає точної та єдиної думки про співвідношення позитивного і негативного тестування.
Існує думка, згідно з якою позитивне тестування вважається більш важливим, ніж негативне.
Уявіть собі ситуацію, при якій наш калькулятор нестійкий до введення некоректних даних (йому складно множити на груші і віднімати апельсини з цілих чисел). Критично це? Ні. Адже користувачі скоро зрозуміють, що не варто виконувати деякі дії зі звичайним калькулятором чисел і не допускатимуть операцій з фруктами і числами одночасно. Але давайте тепер уявімо, що наш калькулятор вірно відповідає на спроби множення апельсинів на цифри, але невірно веде підрахунок математичних операцій з числами, тобто не виконує свою основну функцію (бізнес-завдання).
Тому і вважається, що позитивне тестування важливіше негативного. Окремі помилки при введенні невірних даних рідкісні, а невиконання основної бізнес-функції помітно відразу.
Але не варто думати, що негативні тести нам не потрібні взагалі. Саме вони сприяють появі великої кількості заведених дефектів.
Також існує думка про те, що відділення негативного тестування від позитивного неприпустимо. Адже, по-перше, проведення двох тестів окремо займе більше часу, по-друге, існує ризик пожертвувати негативним тестуванням при нестачі часу і, по-третє, це може суперечити мисленню тестувальника.
Тепер давайте відкладемо наш віртуальний калькулятор цифр і фруктів, і розглянемо кілька реальних прикладів тестових кейсів.
Класичний приклад логіна/логаута:
І ще один приклад створення простого контакту (є можливість перегляду, редагування і видалення):
Якщо у вас при створенні негативних тест-кейсів виникають проблеми, то можете спробувати популярні приклади:
На закінчення хочеться сказати, що вага позитивного і негативного тестування є досить великою, навіть в порівнянні з такими «китами» тестування як функціональне тестування або тестування взаємодії, а отже, ними не варто нехтувати.