Что такое отрицательный кейс
Что такое отрицательный кейс
Если вдруг вам лень читать, то у нас есть еще и видео на эту тему 🙂 https://youtu.be/JOCqwgRO_JQ
Представьте, что перед вами стоит задача проверки поля в форме. С чего начнете? Наверняка найдутся те, кто бросится ломать форму и вводить некорректные данные. Но большинство упомянет о необходимости проведения сначала позитивных проверок, ведь прежде необходимо убедиться, что поле в принципе способно обрабатываться. И уже потом вы перейдете к негативным. И будете правы. Но только в теории. 🙂
На практике же не существует проектов, в которых нужно тестировать со всех сторон единственное поле. Таких полей может быть тысячи и сроки дедлайна (в нашем мире, где они обычно обозначены как «вчера») порой не позволяют провести полностью даже позитивные проверки, не говоря о негативных.
Как быть? Какой приоритет должен быть у негативных проверок? А, может, не проверять негатив вообще? Как это часто бывает, универсального ответа нет, но я постараюсь рассказать о том, как тестирую сама. 🙂
Для начала давайте разберемся с терминами. Какие проверки называть позитивными, а какие негативными.
Общепринятое определение звучит так:
Позитивные проверки — это проверки с данными, введения которых продукт ожидает от пользователя. Например, ожидает от нас система положительного числа в поле цена, мы вводим 100 руб.
Негативные проверки — это, соответственно, те данные, которых программа не ждет. В примере с ценой в негативном тестировании мы введем в это поле буквы, символы и т.п.
С тем, что мы подаем на вход системы, разобрались. Теперь нужно понять, какой результат ждем от выполнения проверок.
С позитивными кейсами ответ однозначный: ввели «хорошие» данные — получили результат “success”. А если вводим «плохие»? Здесь мы столкнулись с некоторой неоднозначностью. У негативных проверок может быть два результата:
То есть у системы есть как минимум три реакции на наши действия по вводу данных:
Исходя из написанного выше, немного усложним формулировки и станем рассматривать определения «позитива» — «негатива» не только со стороны вводимых данных, но и со стороны полученного результата. В этом случае появится еще один тип проверок: условно-негативные. К условно-негативным будем относить все проверки, в которых при введении некорректных данных получаем успешный, с точки зрения логики, результат (сообщение об ошибке).
Теперь вернемся к тому вопросу, который был задан в самом начале: когда и какие негативные проверки стоит проводить?
Для себя я ввела некий условный «Жизненный цикл ПО в негативе». Его идея в том, что количество и тип негативных проверок будет зависеть от того, в какой стадии находится проект.
Проект пока еще как младенец. ЦА вроде бы изучена, аналитики написали первые варианты Технических Заданий (ТЗ), разработчики уже сделали первый вариант продукта и позвали нас тестировать.
На этом этапе мы тестируем самый основной функционал и после прохождения базовых позитивных проверок большая часть наших тест-кейсов будет относиться к негативным и условно-негативным. Как показывает практика, именно на этом этапе большинство заводимых нами дефектов будет связано с отсутствием сообщения с контролем там, где оно должно быть.
На проекте исправлены все «детские болячки», учтены замечания с предыдущего уровня. В ТЗ, при необходимости, добавлены новые контроли. Проект стал похож на тинейджера — почти взрослый, все знает и умеет, но жизненного опыта недостаточно, чтобы справиться с нестандартными ситуациями. На этом этапе более внимательно тестируем позитивные состояния, проводя сложные проверки и применяя различные техники тест-дизайна. При этом уделяем не меньшее внимание и условно-негативным проверкам, ведь наша задача — убедиться, что на каждое действие есть реакция из п.1 или п.2, то есть не возникает отказов.
Проект готов! Он перешел с тестового стенда на прод, стабильно работает и живет взрослой жизнью. Все ошибки давно исправлены, а узкие места известны. На этом этапе мы чаще всего проводим регрессионное тестирование, используя в основном позитивные проверки. Что касается негатива, то оптимальным для данного этапа будет проверка контролей (то есть условно-негативные кейсы) с помощью автотестов. Тем самым на этом этапе время, потраченное на ручное негативное тестирование, минимально и только в случае падения автотестов.
Вывод, который напрашивается из такого разделения, очевиден: чем более ранняя стадия разработки продукта, тем больше времени мы уделяем негативному тестированию. Если же мы имеем дело с давно функционирующим продуктом, без добавления новых фич, то негативное тестирование не будет особенно эффективным. Под проектом вовсе не обязательно понимать всю систему в целом, это правило с легкостью можно применять, например, и просто к новым функциональностям.
Конечно, на деле все не так просто, именно поэтому в начале статьи я сказала о том, что универсального правила когда, сколько и где проводить негативное тестирование — нет. Как нет однозначного ответа на вопрос, где заканчивается позитивное и начинается негативное тестирование, и что вообще понимать под этим процессом.
Например, куда отнести следующий кейс (все совпадения случайны и, наверняка, он был учтен “Амазоном”, но давайте пофантазируем): покупатель зашел в магазин Amazon Go за покупками, съел сэндвич на месте, вернул коробочку из-под него на место и вышел с пустыми руками, без оплаты покупки. С точки зрения линейного процесса и реализованного кода все отработало идеально. С точки зрения бизнес-процесса — это явный fail. Задумались? Куда бы вы отнесли данный кейс? Может, у вас есть свои примеры, доказывающие, что в этом мире нет ничего однозначно черного или белого? Поделитесь в комментариях 😉
Как писать тест-кейсы: полное руководство
💰 Какой была ваша первая зарплата в QA и как вы искали первую работу? Мега-обсуждение в нашем телеграм-канале.
Во время тестирования QA-инженер работает с большим количеством документации. Чеклисты, наборы тестов, тестовые сценарии, планы тестирования, отчеты о тестировании, анализ тестирования — это лишь часть списка документов, которые должны уметь создавать тестировщики. В этой статье мы расскажем вам, как создавать тест-кейсы для ручного тестирования.
Что такое тест-кейс и зачем он нужен
Тест-кейс — это четкое описание действий, которые нужно выполнить для проверки отдельной функции вашего приложения.
Тестировщик создает тест-кейс, чтобы проверить, работает ли определенная фича должным образом, и чтобы подтвердить, что функционал, UI/UX и другие параметры системы удовлетворяют всем соответствующим стандартам, руководствам и требованиям клиентов.
Чем отличаются тест-кейс и чеклист
Тест-кейсы используются для сложных проектов. Например, когда от поведения системы зависит человеческая жизнь. Это могут быть проекты, связанные с пожарной безопасностью, здравоохранением, финансами и т. д. В таких случаях все нужно тестировать очень тщательно.
Чеклист QA — это список того, что нужно протестировать. Благодаря ему процесс тестирования проходит более четко и аккуратно.
Обычно при работе с простыми системами — сайтами, мобильными приложениями и т. д. — нет необходимости в тест-кейсах. Часто в команде бывает только один-два тестировщика, которые хорошо знают свой продукт. В таком случае время, потраченное на создание и поддержку тест-кейсов, никогда не окупится. Лучше создать чеклист со списком функций, которые нужно проверить — это будет более рационально.
Позитивные, негативные и деструктивные тест-кейсы
В позитивных тест-кейсах используются корректные входные данные и сценарии ожидаемой работы системы. Цель здесь — убедиться, что программный продукт выполняет то, что должен делать, и что система не выдаст ошибку, если это не предусмотрено.
В целом позитивное тестирование гарантирует, что система соответствует требованиям при позитивных сценариях нормального использования.
Например, если поле пароля принимает десять символов, пользователь должен иметь возможность создать такой пароль.
Негативные тест-кейсы используют некорректные входные данные и проверяют, не делает ли программа того, чего не должна делать. Негативное тестирование призвано гарантировать, что при получении некорректных входных данных система не будет работать по нормальному сценарию (например, выбросит ошибку).
Если вернуться к нашему примеру, пользователь не должен иметь возможность создать пароль, состоящий из 11 символов.
Деструктивные тест-кейсы создаются, чтобы узнать предел прочности системы. Нагрузочное тестирование — распространенный вариант деструктивного тестирования.
Для деструктивного тестирования QA-специалисты могут применять следующие методы:
Атрибуты тест-кейса для ручного тестирования
Как и все тестировочные документы, тест-кейс имеет определенный формат. Он содержит следующие атрибуты:
Кроме того, для некоторых тест-кейсов могут потребоваться дополнительные атрибуты:
Характеристики хорошего тест-кейса
Прежде всего, тест-кейс не должен быть зависимым или связанным с другими тест-кейсами. Он должен быть полным и самодостаточным. Следует избегать расплывчатых описаний шагов или ожидаемых результатов. Любые ограничения, отсутствие необходимой информации или чрезмерное количество деталей делают тест-кейсы менее эффективными.
Короче говоря, хороший тест-кейс:
Best practices в написании тест-кейсов
Под best practices мы подразумеваем правила, которые помогают создавать простые, понятные и полезные тест-кейсы:
Формирование тест-кейсов
Обычно при написании тест-кейсов тестировщики пользуются таблицами Excel. Но вы также можете использовать инструменты управления тестированием, такие как TestRail.
Примеры тест-кейсов для ручного тестирования
Позитивный тест-кейс
Давайте попробуем создать наш собственный тест-кейс для ручного тестирования функции поиска на e-commerce сайте компании FootWear. Начнем с позитивного теста.
ID: FWSF-1. (Лучше использовать числа в возрастающем порядке. FWSF = FootWear Search Functionality. Попробуйте придумать комбинацию букв, имеющую отношение к проекту или функции, которую вы собираетесь тестировать).
Заголовок: Проверить результаты поиска с корректными входными данными. (Узнать, какие значения допустимы, мы можем в требованиях).
Предусловия: Нужно иметь предварительно настроенные продукты из разных категорий, отображаемые на сайте. (Для проверки функциональности нам необходимо иметь элементы, доступные для поиска. Вы можете настроить это в панели администратора или в базе данных).
Шаги:
Ожидаемый результат: На странице результатов поиска отображаются все релевантные результаты.
Деструктивный тест-кейс
Еще один пример — деструктивный тест-кейс.
ID: FWSF-2.
Заголовок: Проверить устойчивость поиска к SQL-инъекциям.
Предусловия: Подготовьте SQL-запрос, который вы собираетесь вставить в поиск.
Шаги:
Ожидаемый результат: Для защиты от SQL-инъекций отображение предупреждающих сообщений должно быть отключено.
Негативный тест-кейс
Наконец, вот вам негативный тест-кейс.
ID: FWSF-3.
Заголовок: Проверить ввод на недопустимые значения.
Предусловия: Выпишите недопустимые значения для поля ввода поиска из системных требований.
Шаги:
Ожидаемый результат: Отображается предупреждающее сообщение «Пожалуйста, используйте только допустимые символы». Поиск можно продолжить.
Итоги: тестирование тест-кейса
Итак, мы разобрали основы написания тест-кейсов. Совет напоследок: чтобы проверить, насколько хорош ваш тест-кейс, покажите его человеку, который ничего не знает о проекте, над которым вы работаете. Вопросы, которые вы услышите, помогут определить слабые места вашего тест-кейса. Обратите внимание на эти моменты и постарайтесь внести изменения как можно скорее, иначе в будущем для поддержки тест-кейсов потребуется гораздо больше времени и усилий.
Немного о простом. Тест-дизайн. Часть 1
Сегодня тестирование ПО, один из ключевых процессов создания продукта. Неважно, какую Вы используете методологию, подход, процесс, тестирование ПО так или иначе всегда существует в Вашем процессе. В последние годы (да даже наверное десятилетие) тестирование ПО сформировалось в отдельную область ИТ, которая постоянно развивается в мировом сообществе.
И да, сегодня мы поговорим именно об обычных ручных (функциональных) тестировщиках, без уклона в автоматизацию, нагрузку и другие технические виды тестирования!
Сейчас профессия ручного тестировщика – это одна из самых востребованных процессий ИТ и один из самых простых способов попасть в ИТ.
Потому что тестировщики ничего не делают, им не нужны знания. Тестировать может каждый!
Потому что профессия ручного тестировщика на начальном этапе не требует специфических знаний и умений. Основное «знание» для тестировщика – это умение «разрушать» и аналитическое мышление. А главное – иметь нестандартный склад ума, находить нетривиальные решения поставленных задач. Некий монстр, умеющий крушить и ломать:)
Hard skills всегда можно научить, а вот soft skills к сожалению научить очень сложно, потому что это характер человека, его отношение к чему-либо и т.д. Обычно я косо смотрю на руководителей, которые набирают себе специалистов по ручному тестирования по hard skills. Зачем Вы это делаете. (ответы можете оставить в комментариях) Ну да ладно, продолжим:)
Если рассматривать технические особенности тестирования, которые должен знать ручной тестировщик, то их можно поделить на 2 основных части возможно многие со мной не согласятся, будут кричать как же так, ты не прав, тестирование это очень сложно – это подготовка к тестированию и выполнение тестирования.
Мы с вами рассмотрим самую интересную и увлекательную часть тестирования – подготовку к тестированию. Именно от этой части процесса тестирования зависит то, насколько качественно и правильно вы выполните само тестирования, найдете необходимые дефекты и обеспечите довольное лицо Заказчика (ну или продукт овнера) качество задачи после внедрения.
Многие из вас, кто занимался тестированием, так или иначе, занимался подготовкой к тестированию. Отличие обычно лишь в том, насколько вы этот этап процесса тестирования формализуете. Если вы занимаете исследовательским тестированием, не пишите тестовые сценарии, вам дают систему и вы сразу кидаетесь в бой, все равно, вы готовитесь к тестированию. Зачастую, на несложных проектах, тестировщик может не замечать этого, потому что этап аналитики и подготовки к тестированию проходит у вас на бессознательном уровне. Но даже если так, он все равно есть.
И в этом цикле статей поговорим об этом.
У себя на работе я часто провожу обучения для ручных тестировщиков, и сталкиваюсь с ситуациями, что вроде все слышали о техниках тест дизайна, но в работе их никто не применяет.
Первое, когда тестировщиков учат на курсах по тестированию (или самообучение по книгам и статьям), то им рассказывают, как применять техники тест-дизайна на элементарных примерах. И главная проблема такого обучения, что тестировщики не могут перенести полученные знания на свои реальные задачи. То есть использовать техники тест-дизайна в повседневной работе.
Второе, при обучении техникам тест-дизайна, данный процесс очень формализуется, что выглядит, как необходимость тестировщику в своей работе все формализовать. А обычно это никому не надо времени на это ни у кого нет.
Если говорить простыми словами, то техники тест-дизайна – это совокупность правил, позволяющих правильно определить список проверок для тестирования. И самое важное, это использовать эти правила всегда и везде 🙂 уметь на интуитивном уровне применять данные правила. Именно умение «проводить аналитику в голове» отличает хорошего тестировщика!
В моей организации, как и общепринятых стандартах и практиках, задачами тест-дизайна являются:
А начнем мы с самого простого, а именно о 2-х основных техниках тест-дизайна, про которые все слышали, и я уверен, применяли, но скорее всего на интуитивном уровне в своей работе.
Это классы эквивалентности и граничные значения.
Что же такой классы эквивалентности?
Класс эквивалентности (Equivalence class) – это набор входных (или выходных) данных ПО, которые обрабатываются программой по одному алгоритму или приводят к одному результаты.
То есть, это некое множество значений, которое вы можете подставлять в программу и получать один и тот же результат. Результатом можем быть не только конкретные значения, действия программы, но и просто область применения. Поэтому, самые простые классы эквивалентности, на которые делятся проверки, это 2 основных класса: позитивные и негативные сценарии.
Они есть всегда. Каждый тестировщик делит проверки на эти классы, но не каждый тестировщик знает, почему он это делает. Ответ – классы эквивалентности.
Далее, каждый класс эквивалентности можем разделить на дополнительные классы и т.д. до того момента, пока проверки не будут приводить к точечным и конкретным результатам тестирования.
Система скорринга рассчитывает процентную ставку по кредиту для клиента исходя из его возраста, который вводится в форму:
Позитивными сценариями будут все значения, которые приводят к получению результата, негативными сценариями – значения, результаты которых не описаны, как ожидаемый результат.
Далее мы делим класс позитивных сценариев 3 класса вводимых значений 18-24, 25-44 и 45 +
В классе негативных сценариев мы формируем значения, исходя из необходимости проверки отказов программы, поэтому мы имеем 0, 1-17, отрицательные значения, ввод символов и т.д.
Результатом данного разбиения будет значение или диапазон значений, в котором нам необходимо выполнить всего одну проверку с любым значением из диапазона данных. Могут возникнуть такие ситуации, как одно значение в диапазоне. Это тоже отдельный класс эквивалентности и тоже требует проверки.
Еще одна особенность классов эквивалентности – это их применение. Я выделяю 3 уровня применения техник тест-дизайна для подготовки к тестированию.
Классы эквивалентности в большей степени относятся к 1-му уровню и применяются для проверки элементов программы. Но идеологически, данный подход можно применять и для других уровней.
Неотъемлемой часть проверки любого элемента является другая техника – граничные значения.
Граничные значения дополняют эквивалентные классы, тем самым полностью покрывая проверки элемента ПО.
Граничные значения – техника тест-дизайна, которая дополняет классы эквивалентности дополнительными проверками на границе изменения условий.
Вернемся к нашему примеру ранее.
Система скорринга рассчитывает процентную ставку по кредиту для клиента исходя из его возраста, который вводиться в форму:
Если вы подумали о длине поля на страничке Хабры, или об отпуске в теплых странах, хочу вас расстроить, это не так 🙂
Что определить граничные значения нужно нечто иное. А именно, определить, какие значения являются начальным и конечным для нашего класса. И самое важное. Годы исследований в области тестирования показали, что бОльшая часть дефектов находится тестировщиками именно на стыке значений, которые меняют условия работы программы.
Поэтому, помимо граничного значения мы используем для тестирования дополнительно 2 значения, значение перед границей и значение после границы.
Границы наших классов: 17, 18, 19, 24, 25, 26, 44, 45, 46 и max.
Далее исключаем повторяющиеся значения, и получаем значения для проверки элемента ввода данных.
-1, 0, 1, 17, 18, 19, 24, 25, 26, 44, 45, 46, max.
Значение max обычно уточняется у Заказчика или аналитика. Если не могут предоставить, то следует бросить его и не проверять необходимо подобрать значение, соответствующее здравому смыслу (вряд ли кто-то придет за кредитов в возрасте 100 лет).
Следующий шаг, это наложить граничные значения на значения классов эквивалентности, исключить лишние проверки, пользуясь правилом «достаточно одного значения для проверки одного класса» и финализировать список.
Если ранее у нас были 3 значения для 3-х классов, 19, 30 и 48, то после определения граничных значений, мы можем исключить из списка значения 30 и 48 и заменить их предграничными значениями, такими как 26 (вместо 30) и 46 (вместо 48).
Граничные значения определяются не только для числовых значений, но и для буквенных (например, границы алфавита и кодировки), даты и времени, смысловых значений. Граница числовых значений зависит от формата ввода, если у вас целые числа, например, 2, то граничные значения будут 1 и 3. Если дробные значения, то границы для числа 2 уже будут 1,9 (1,99) или 2,1 (2,01) и т.д.
Техники тест-дизайна 1-го уровня достаточно просты и понятны. Я думаю, вы скажете, да это легко, но зачем досконально проверять каждый элемент. И будете правы.
Чаще всего их применяют при разработке нового ПО, потому что единожды после проверки элементов системы при разработке они в дальнейшем не часто подлежат изменению на уровне работы элемента. Не нужно постоянно проверять каждое значение элемента в каждом экране вашей программы, но имейте ввиду, что если изменяется логика обработки данных в элементах программы, необходимо повторно убедиться в правильности обработки значений элемента.
Что ж, слишком легко. Сейчас начнем разбирать более сложные техники, готовьтесь.
Техники тест-дизайна 2-го уровня отвечают за вариативность и комбинаторику данных при проверке ПО.
Основной техникой тест-дизайна parwise testing (попарное тестирование). Суть техники заключается в минимизации вариативности комбинаций проверок, достаточных для обеспечения высокого качества ПО.
Простыми словами, в данной технике применяется правило Парето, 80 % качества можно достичь всего 20% проверок комбинаций данных.
Данная техника была выведена путем более 15-тилетнего исследования IEEE в области анализа причин возникновения дефектов в системе. Результаты исследования показали, что 98% всех дефектов возникают при конфликте ПАР входных данных или ОДНОГО входного параметра.
Почему же была выбрана пара? Погрузимся в дебри математической статистики и теории вероятности, чтобы найти ответ.
Конечно мы туда не пойдем нынче теория вероятности слишком сложна для простых ИТшников, все просто, возьмем обычную игру в кубик с 6-ю гранями.
Пусть выпадение значения 2 – это дефект, тогда вероятность появления дефекта при кидании кубика равна 1/6=0,167.
Если мы бросаем 2 кубика, то вероятность выпадения 2-х двоек (2 дефекта) становиться ниже и равна 0,167*0,167 = 0,028, для 3-х уже 0,005 и т.д.
Получается, что вероятность возникновения дефекта при комбинации 3-х и более параметров настолько мала, что ее можно отбросить.
Когда мы с вами тестируем программу, всегда есть n количество элементов, которые влияют на результат, например, форма заполнения данных по кредитной заявке. Там есть n количество полей, которые в совокупности дают результат. Именно комбинаторику данных при заполнении полей мы проверяем с помощью попарного тестирования.
Давайте рассмотрим на примере функциональности дистанционного оформления карты в банке.
Если мы внимательно посмотрим, то увидим с Вами пять полей заполнения данных:
Очень ВАЖНО, при использовании техники попарного тестирования, мы не говорим о результате тестирования. Нам важно проверить вариативность данных при заполнении заявки.
Поле ФИО может принимать значения (классы):
Идем дальше, дата рождения, также как и мобильный телефон, серия и номер паспорта можем иметь тоже 3 состояния:
Чтобы проверить все комбинации данной формы нам бы понадобилось сделать свыше 1000 тестов, но используя попарное тестирование нам достаточно всего 9 тестов!
Магия, не думаю:)
Следующий шаг – составление ортогонального массива с комбинациями данных. Самым простым способом составления массива является попарное заполнение данными, начиная с элементов, имеющих наибольшее количество значений и далее по убыванию. Так как в нашем примере есть 4 элемента с одинаковым количеством значений, то мы можем выбрать любую пару.
Мы берем ФИО и серия номер паспорта. Наша задача – перебрать все значения данной пары между собой:
После перебора одной пары, мы создаем другую пару и начинаем перебирать значения (например номер мобильного телефона)
Подключаем следующий элемент и так далее до полного заполнения всей таблицы, которая будет выглядеть так:
Таким образом мы получаем 9 тестов с конкретными классами эквивалентности, которые мы можем вводить для проверки работы вариативности данных для формы. Классы мы можем заполнять конкретными значениями, которым мы получаем с вами используя 1 уровень техник тест-дизайна.
В заключении данной статьи скажу, что рассмотренные техники тест-дизайна покрывают только часть проверок для тестирования программы, а именно проверка корректности работы элементов программы и результата их комбинаций в процессе ее работы. Во второй части мы перейдем к техникам тест-дизайна, позволяющим творить чудеса тестирования тестировать логику работы программы и процессы. Это очень важная составляющая ручного тестирования, и именно ее зачастую Вы тестируете на своей работе!