На своих курсах по обучению начинающих тестировщиков я предлагаю им написать позитивные и негативные тесты на:
- Функцию вычисления корня в калькуляторе.
- Работу с корзиной (добавление / удаление / редактирование) в интернет-магазине.
И вот что я заметила — с позитивным тестированием все хорошо, ребята придумывают разные виды тестов (потому что задача назвать несколько, а не перечислить все-все-все, поэтому, даже работая в команде, можно не повторяться). А вот с негативным у многих возникают проблемы, просят пояснить, потому что «ничего кроме ввода символов в числовое значение числа товаров в корзине да вычисления корня из отрицательного числа на ум не приходит».
Поэтому я решила написать поясняющую статью.
Позитивное тестирование
Тестировщик — это человек, который предоставляет команде информацию о продукте. Вот решили мы сделать тот же самый интернет-магазин, продумали концепцию, написали код и теперь задача тестирования — рассказать, работает ли все так, как нам нужно.
И конечно же, огромное значение имеют именно позитивные тесты. Если пользователь зайдет к нам на сайт и не сможет положить товар в корзину, то ему будет глубоко наплевать, что при вводе всяких спецсимволов или sql-инъекций мы пишем красивые сообщения об ошибке.
Поэтому, когда нам дают что-то потестировать, можно радостно кинуться ломать новые формочки, но нужно сначала проверить корректные сценарии. Сначала удовлетворяем лояльных и грамотных пользователей, а потом уже делаем все остальное.
Таким образом, позитивное тестирование направлено на то, чтобы убедиться, что основной функционал работает. Все сценарии использования нашей системы выполнимы и приводят к ожидаемому результату, а не к ошибкам.
Посмотрим на примерах:
Основной тест-кейс — проверить, что корень из корректного числа действительно вычисляется.
- После вычисления корня остается целое число (корень из 4 = 2)
- После вычисления корня остается дробное число (корень из 3)
Хм, а что, если дробное число у нас будет не только после вычисления корня, но и до? Можем же мы взять корень из числа 2,2 ? Позитивный тест? Позитивный!
Также можно разделить числа на небольшие, до 100, например. Потом взять интервал от 100 до размера int и третий будет еще больше, сколько влезает в наш калькулятор. 3 класса эквивалентности, проверяем по одному значению из интервала.
Не забудем и про граничные значения, проверим 0. Позитивный тест? А как же! Корень из 0 равен 0, а не ошибке!
Из основного, пожалуй, все.
2. Работа с корзиной в интернет-магазине.
О, вот где простор для воображения!
Пользователь столько разных сценариев может выполнить!! Но в первую очередь возьмем основные, самые короткие. Потому что если уж они не работают, то длинные цепочки (добавил — отредактировал — удалил — снова добавил — итд) проверять точно не стоит. Итак:
- Добавление товара в корзину.
- Добавление второго товара в корзину (того же самого, счетчик должен увеличиться).
- Добавление второго товара другого типа.
- Редактирование числа товаров, находящихся в корзине, увеличение на несколько, уменьшение.
- Удаление товара из корзины.
- Ваш вариант
Придумать тестов здесь можно очень много. Особенно, если начать проверять цепочки, например, добавил товар в корзину — передумал, удалил — ой, нет, все-таки надо, снова добавил.
Думаете, будет работать, если работает по отдельности? Не-е-е-ет, ребята, вы же тестировщики! Никогда не верьте программам «на слово»! Придумали сценарий? Проверьте!
Тем более что такой сценарий вполне может упасть, мы же уже удалили данный товар из корзины, так? Так вот система вполне может не дать нам его снова добавить. Типа «ты уже отказался, але, я все помню!». Корректно такое поведение? Нет!
А сам сценарий позитивный? Да! Хотя уже и с нотками извращения, надо признать 
Надо помнить, что негативное тестирование не менее важно, чем позитивное. Потому что наши пользователи — люди, а не роботы. А людям свойственно ошибаться. И всегда надо помнить про данный человеческий фактор.
Если я приду на сайт, сделаю заказ и все будет хорошо — я приду туда еще раз. Но если я приду, сделаю заказ и случайно где-то ошибусь, например, вставлю скопированное в аське сообщение вместо цифры, то я хочу увидеть тактичное замечание, а не краш всей системы.
Вообще в наше время обычно для решения проблемы пользователя (например, что-то купить надо) существует большой выбор сайтов. Посмотрев на них и поняв, что функциональность, нужная ему, есть везде, пользователь выберет наиболее красивенький и удобный сайт.
Но, как бы не был такой сайт удобен, если он не в состоянии отработать при влиянии человеческого фактора, пользователь рано или поздно уйдет. «Шаг влево, шаг вправо — расстрел», кому это понравится? Хочется иметь возможность ошибаться и исправлять ошибки, а не получать «по рукам» страшными сообщениями об ошибке на весь экран.
Поэтому мы проводим негативное тестирование. Что такое негативное тестирование? Это ввод заведомо некорректных данных. Вводим и смотрим, как ведет себя программа, понятные ли сообщения об ошибке выдает…
Но как составлять такие тесты? Посмотрим на примерах:
Но что еще тут можно придумать?
- Корень из пустоты — вспоминаем о граничных значениях, мы не можем ввести строку отрицательной длины, но вот граничное значение (строка нулевой длины) можем!
- Корень из символов — надо проверить, что скажет система, если ввести или вкопипастить туда что-то символьное. Причем символы мы делим на русские, английские и спецсимволы!
- Корень из значения «четыре» — также символы можно поделить на абракадабру и «типа число». Кстати, если уж говорить о таких «типа числах»…
- Попробуем ввести строку, которая обозначает число. И взять корень уже из нее.
Видите? На самом деле тестов не так уж и мало! Отдельно хочется высказать на тему «ввести очень большое число, максимально большое». Попробовать можно, почему нет? Но это более негативно скажется на сценарии возведения в квадрат, чем на вычислении корня.
В корне можно не вводить максимально большое число, а ввести такое число, чтобы корень из него (дробное значение) получился очень длинный и не уместился на экран, вот что тогда будет, обрежется или сломается?
2. Работа с корзиной в интернет-магазине.
Тут, опять же, можно найти числовое поле и поиграться с ним, как мы это только что проделали с калькулятором. Поле «количество товара» тут очень подойдет! Но, с другой стороны, скучно же, такие разные приложения и одни и те же тесты?
Кстати, не хочу сказать, что их не надо проводить. Надо, еще как надо! Просто я в статье повторяться уже не буду. Хочется здесь упомянуть о важной особенности всяких web-приложений и главном негативном тесте, который обычно все и ломает.
Запомните всего 2 слова — разные вкладки!
Чувствуете? Давайте поясню. Негативный тест на удаление товара из корзины — попытаться удалить уже удаленный товар. И тут начинаются варианты, как это может быть сделано:
- Открыли корзину в 2 вкладках браузера. Сначала нажали «удалить» в одной, потом во второй. То есть попытка удалить то, что ты сам уже удалил из своей же корзины.
- Попытка удалить удаленный админом товар. В 1 вкладке под админом удаляем товар вообще, в принципе, а в другой пытаемся его под пользователем удалить из корзины.
И кстати, также можно попробовать добавить удаленный админом товар или отредактировать его количество. А еще админ может не удалить товар, а перенести его в другую категорию. И вот тут сломаться ничего не должно!!! Если в случае удаления мы должны увидеть корректное сообщение об ошибке, то в случае переноса просто продолжить работу.
А что будет, если админ не передвинул товар в иерархии магазина (в другую категорию переместил, исходно неверно был размещен товар), а просто поправил, отредактировал описание? Тоже ничего сломаться не должно!
И даже если у нас не магазин, а что-то другое, всегда задумайтесь, как можно попытаться применить технику разных вкладок.
Например, мы можем создавать карточку — человека, здания, той же книги, чего-то еще… Попробуйте ее отредактировать в 2 окна. В одном изменить одно поле, сохранить, а потом во втором изменить другое поле и тоже сохранить. Или что-то удалить, а во втором окне добавить или изменить.
Всегда пробуйте играться такими вещами, это часто заканчивается плачевно для программы. И даже если команда примет решение пока не исправлять такие дефекты как не критичные, неважно. Нам главное о них знать! Предоставьте информацию, а потом уже решайте, что с ней делать…
Хочется привести еще один пример из реальной практики. Тоже web-интерфейс, в котором можно нажать «создать» и добавить новую карточку. Пользователь добавляет, а у него через раз формочка падает. Почему?
Стали выяснять. И поняли. Пользователю надо было завести сразу много карточек (миграция), вот он и нажимал на «создать» несколько раз, зажав Ctrl (открыть в новой вкладке). И потом уже ходил по вкладкам и создавал.
Вот казалось бы, где тут негативное тестирование? Ведь пользователь не вносит противоречивых изменений, меняя одну и ту же карточку. Нет, он создает новые, то есть вносит информацию в разные карточки. Но вот ведь как, система считала открытое окно «новая карточка» чем-то одним, громко возмущаясь наглым попыткам пользователя запихать туда то одну информацию, то другую.
Так что, ребята, дерзайте! Открывайте разные вкладки и вперед, ищите информацию о том, как же, ну как же ведет себя именно ваша программа при противоречивых воздействиях на нее? 
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Автор статьи: Ольга Назина
ООО «Тестбейз», ИНН 9727006330, ОГРН 1227700497309
Она же — ИП Назина Ольга Евгеньевна, ИНН 772791965180, ОГРНИП 315774600011282