Что такое негативное тестирование
Что такое негативное тестирование
Что пишут в блогах
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова
Мы, как тестировщики и автоматизаторы, часто обдумываем «Счастливый путь» – сценарий, которым пользователь с наибольшей вероятностью воспользуется в нашем приложении. Создавая автоматизированные UI-тесты, мы стремимся убедиться, что эти сценарии автоматизированы, а автоматизируя API, хотим проверить, что каждая конечная точка вернет «200 ОК» или схожий успешный ответ.
Однако о негативном тестировании тоже важно думать – как при ручном, так и при автоматизированном тестировании, и вот почему:
Наши автоматизированные тесты могут проходить по неправильным причинам
Когда я только начинала писать автоматизированные UI-тесты на JavaScript, я не понимала концепцию контейнеров. Я просто предполагала, что если я запрашиваю нахождение элемента, то элемент не будет возвращен, пока не будет найден. Я была так рада, когда мои тесты начали проходить с зеленым «успешным» результатом, пока коллега не предложил попробовать заставить тест упасть, задав ему другое утверждение для проверки. Тест снова прошел, потому что просто удостоверялся в существовании контейнера, а оно всегда возвращалось как истина. Я получила ценный урок – никогда нельзя предполагать, что автотесты правильно работают только потому, что они успешно проходят. Убедитесь, что вы проверили сценарии, при которых ваши тесты обязаны упасть, и проверьте, что они действительно падают. В этом случае вы удостоверитесь, что действительно тестируете то, что планировали протестировать.
Негативное тестирование может выявить неправильную обработку ошибок, которая может повлиять на пользователя
При тестировании API любая клиентская ошибка должна возвращать ответ уровня 400, а не 500. Если в ходе негативного тестирования ошибки 403 теперь приходят как 500, это может означать, что код перестал правильно справляться с таким сценарием использования. Ответ 500 от сервера может помешать пользователю получить информацию, которая нужна ему для исправления ошибки – или, что еще хуже, приложение может упасть.
Негативное тестирование может выявить уязвимости безопасности
Убедиться, что пользователь не может авторизоваться в приложении, если не должен, не менее важно, чем убедиться в возможности авторизации. Если вы проводите тест авторизации только с валидной парой логин-пароль, вы упускаете этот важный момент! Я сталкивалась с ситуациями, когда пользователь мог авторизоваться с чем угодно в роли пароля, с пустым паролем, и со случаем, когда неверны были и логин, и пароль, но авторизация осуществлялась.
Важно также проверить, что у определенных пользователей нет доступа к определенным областям приложения. Тщательно протестированная и функционирующая панель администратора – штука бессмысленная, если окажется, что доступ к ней может получить кто угодно.
Негативное тестирование хранит чистоту базы данных
Как я упоминала в своей предыдущей статье про тестирование валидации ввода, хорошие валидные данные в базе помогут поддерживать здоровье вашего приложения. Данные, не соответствующие ожиданиям, могут заставить страницу упасть или отказаться грузиться, или привести к неправильному отображению информации. Чем больше негативного тестирования вы проведете для ввода, тем лучше удостоверитесь, что ваши данные хороши.
Для каждого поля ввода, которое я тестирую, я выясняю, какие конкретно символы в нем разрешены. Затем я могу прогнать целую пачку негативных тестов, чтобы удостовериться, что запрещенные символы приводят к ошибке.
Иногда пользователи идут по негативному сценарию
Очень легко – особенно в гонке тестирования новой фичи, дабы успеть к дедлайну – забыть проверить пользовательские сценарии, при которых пользователь нажимает на кнопки отмены или удаления. Однако люди делают это постоянно – подумайте о ситуациях, когда вы хотели что-то заказать онлайн, а затем передумали и удалили товар из корзины. Представьте свое раздражение, если он не удалится, или если кнопка отмены не очистит форму, чтобы дать вам возможность начать заново. Пользовательский опыт в этой области не менее важен, чем при «счастливом пути».
Тестирование – это поиск неожиданного поведения с целью найти его раньше пользователя. Когда негативное тестирование комбинируется со сценариями счастливого пути, мы можем удостовериться, что пользователь не столкнется с неприятными сюрпризами.
говориМ о тестировании
простым языком
Виды тестирования по позитивности сценария
Позитивное тестирование – это тестирование с применением сценариев, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. С его помощью мы можем определить, что система делает то, для чего и была создана.
Негативным называют тестирование, в рамках которого применяются сценарии, которые соответствуют внештатному поведению тестируемой системы. Это могут быть исключительные ситуации или неверные данные.
Прежде всего негативное тестирование направлено на проверку устойчивости системы к различным воздействиям, валидации неверных данных, обработку исключительных ситуаций. Сценарии позитивного тестирования, в свою очередь, направлены на проверку работы системы с теми типами данных для которых, она разрабатывалась.
Реакция продукта на тесты
Какой результат мы ждем от позитивных и негативных тестов?
Позитивное тестирование должно нам всегда давать результат в виде отсутствия багов.
Негативные проверки могут дать 2 результата:
1. На данный ввод у продукта есть ответ в виде сообщения/контроля.
2. Система не знает, как реагировать на введенные данные.
Получается, есть три реакции на действия по вводу данных:
— Действие: создание сущности, переход на новый шаг и т.п.
— Контроль: сообщение с контролем, блокировка дальнейших действий и т.п.
— Отказ: возникает исключение Exception, 404-ой ошибки и т.п.
Для чего важно различать?
Для чего нам различать негативное и позитивное тестирование? Чтобы верно расставлять приоритеты в тестировании в зависимости от ситуации.
Создание позитивных сценариев (тест-кейсов), как правило, предшествует созданию негативных.
Сначала мы проверяем работу системы, когда наш условный пользователь работает с системой «правильно». А уже потом приступаем к проверке отклика системы на пользователя, который допускает различные ошибки (ввод неверных данных, например). И наша система должна быть готова ответить на неверный запрос. Это и есть цель негативного тестирования.
Почему важно сначала провести позитивное тестирование? Большинство пользователей использует наш продукт так, как необходимо. То есть, если в поле ввода просят указать «Имя», то большинство пользователей напишут в него именно имя, а не набор цифр. Если мы не проверим верно ли распознаются корректные данные, то в случае ошибки большинство пользователей не смогут воспользоваться нашим продуктом.
Именно поэтому мы делим все тесты на позитивные и негативные и начинаем тестировать с позитивных. Именно с позитивных, так как они приоритетней. Лучше не останется времени на негативные тесты, чем мы не проверим основной функционал продукта на способность корректно отвечать пользователю на корректные запросы.
Пример позитивных и негативных тестов
Давайте рассмотрим эти виды тестирования немного подробнее на примере формы авторизации на сайте.
С помощью позитивных тестов мы проверим, что наша форма регистрации работает верно. Для этого проведем следующие тесты:
К негативным тестам можно отнести следующие сценарии:
Повторюсь, при тестировании очень важно соблюдать приоритет.
Сначала мы выполняем позитивные тесты, а потом негативные.
Это связано с тем, что для продукта и пользователей важно, чтобы все фичи работали правильно, так как задумывались изначально.
К примеру, ошибка при авторизации с правильным логином и паролем гораздо опаснее, чем проблема возникающая, когда пользователь вводит неправильный пароль. А критичные ошибки лучше всегда находить как можно раньше, чтобы было время их исправить и внимательно проверить.
Что такое негативное тестирование
Если вдруг вам лень читать, то у нас есть еще и видео на эту тему 🙂 https://youtu.be/JOCqwgRO_JQ
Представьте, что перед вами стоит задача проверки поля в форме. С чего начнете? Наверняка найдутся те, кто бросится ломать форму и вводить некорректные данные. Но большинство упомянет о необходимости проведения сначала позитивных проверок, ведь прежде необходимо убедиться, что поле в принципе способно обрабатываться. И уже потом вы перейдете к негативным. И будете правы. Но только в теории. 🙂
На практике же не существует проектов, в которых нужно тестировать со всех сторон единственное поле. Таких полей может быть тысячи и сроки дедлайна (в нашем мире, где они обычно обозначены как «вчера») порой не позволяют провести полностью даже позитивные проверки, не говоря о негативных.
Как быть? Какой приоритет должен быть у негативных проверок? А, может, не проверять негатив вообще? Как это часто бывает, универсального ответа нет, но я постараюсь рассказать о том, как тестирую сама. 🙂
Для начала давайте разберемся с терминами. Какие проверки называть позитивными, а какие негативными.
Общепринятое определение звучит так:
Позитивные проверки — это проверки с данными, введения которых продукт ожидает от пользователя. Например, ожидает от нас система положительного числа в поле цена, мы вводим 100 руб.
Негативные проверки — это, соответственно, те данные, которых программа не ждет. В примере с ценой в негативном тестировании мы введем в это поле буквы, символы и т.п.
С тем, что мы подаем на вход системы, разобрались. Теперь нужно понять, какой результат ждем от выполнения проверок.
С позитивными кейсами ответ однозначный: ввели «хорошие» данные — получили результат “success”. А если вводим «плохие»? Здесь мы столкнулись с некоторой неоднозначностью. У негативных проверок может быть два результата:
То есть у системы есть как минимум три реакции на наши действия по вводу данных:
Исходя из написанного выше, немного усложним формулировки и станем рассматривать определения «позитива» — «негатива» не только со стороны вводимых данных, но и со стороны полученного результата. В этом случае появится еще один тип проверок: условно-негативные. К условно-негативным будем относить все проверки, в которых при введении некорректных данных получаем успешный, с точки зрения логики, результат (сообщение об ошибке).
Теперь вернемся к тому вопросу, который был задан в самом начале: когда и какие негативные проверки стоит проводить?
Для себя я ввела некий условный «Жизненный цикл ПО в негативе». Его идея в том, что количество и тип негативных проверок будет зависеть от того, в какой стадии находится проект.
Проект пока еще как младенец. ЦА вроде бы изучена, аналитики написали первые варианты Технических Заданий (ТЗ), разработчики уже сделали первый вариант продукта и позвали нас тестировать.
На этом этапе мы тестируем самый основной функционал и после прохождения базовых позитивных проверок большая часть наших тест-кейсов будет относиться к негативным и условно-негативным. Как показывает практика, именно на этом этапе большинство заводимых нами дефектов будет связано с отсутствием сообщения с контролем там, где оно должно быть.
На проекте исправлены все «детские болячки», учтены замечания с предыдущего уровня. В ТЗ, при необходимости, добавлены новые контроли. Проект стал похож на тинейджера — почти взрослый, все знает и умеет, но жизненного опыта недостаточно, чтобы справиться с нестандартными ситуациями. На этом этапе более внимательно тестируем позитивные состояния, проводя сложные проверки и применяя различные техники тест-дизайна. При этом уделяем не меньшее внимание и условно-негативным проверкам, ведь наша задача — убедиться, что на каждое действие есть реакция из п.1 или п.2, то есть не возникает отказов.
Проект готов! Он перешел с тестового стенда на прод, стабильно работает и живет взрослой жизнью. Все ошибки давно исправлены, а узкие места известны. На этом этапе мы чаще всего проводим регрессионное тестирование, используя в основном позитивные проверки. Что касается негатива, то оптимальным для данного этапа будет проверка контролей (то есть условно-негативные кейсы) с помощью автотестов. Тем самым на этом этапе время, потраченное на ручное негативное тестирование, минимально и только в случае падения автотестов.
Вывод, который напрашивается из такого разделения, очевиден: чем более ранняя стадия разработки продукта, тем больше времени мы уделяем негативному тестированию. Если же мы имеем дело с давно функционирующим продуктом, без добавления новых фич, то негативное тестирование не будет особенно эффективным. Под проектом вовсе не обязательно понимать всю систему в целом, это правило с легкостью можно применять, например, и просто к новым функциональностям.
Конечно, на деле все не так просто, именно поэтому в начале статьи я сказала о том, что универсального правила когда, сколько и где проводить негативное тестирование — нет. Как нет однозначного ответа на вопрос, где заканчивается позитивное и начинается негативное тестирование, и что вообще понимать под этим процессом.
Например, куда отнести следующий кейс (все совпадения случайны и, наверняка, он был учтен “Амазоном”, но давайте пофантазируем): покупатель зашел в магазин Amazon Go за покупками, съел сэндвич на месте, вернул коробочку из-под него на место и вышел с пустыми руками, без оплаты покупки. С точки зрения линейного процесса и реализованного кода все отработало идеально. С точки зрения бизнес-процесса — это явный fail. Задумались? Куда бы вы отнесли данный кейс? Может, у вас есть свои примеры, доказывающие, что в этом мире нет ничего однозначно черного или белого? Поделитесь в комментариях 😉
понедельник, 10 февраля 2014 г.
Позитивное и негативное тестирование
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
36 комментариев:
Две из трех основных парадигм расписаны, это хорошо )
Впринципе, можно было бы уложиться в несколько строчек.
1. Тестирование на позитивных значениях.
Обычно используются пользовательские сценарии с корректными значениями.
Проверяем работоспособность заявленного функционала.
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 уровень техник тест-дизайна.
В заключении данной статьи скажу, что рассмотренные техники тест-дизайна покрывают только часть проверок для тестирования программы, а именно проверка корректности работы элементов программы и результата их комбинаций в процессе ее работы. Во второй части мы перейдем к техникам тест-дизайна, позволяющим творить чудеса тестирования тестировать логику работы программы и процессы. Это очень важная составляющая ручного тестирования, и именно ее зачастую Вы тестируете на своей работе!