подход к тестированию который также можно отнести к техникам тест дизайна

Тест-дизайн. Когда и для чего

Предположим простую ситуацию. Вам дали тестировать сайт с описанием фильмов. Там около 1000 страниц. Простой вопрос, что тестировать?

Всегда существует вариант — тестировать “в лоб”. Открываем каждую страницу, проверяем на месте ли текст и картинки, смотрим, что расположение элементов не поехало и все стоит на своих местах. Звучит как-то не очень весело, не правда ли? Я уже не говорю о потраченном времени.

Или, например, у нас есть интернет-магазин, в котором около 5000 товаров. Получается, для того, чтобы проверить покупку товаров, нам необходимо зайти в каждый и купить?

Но это еще ерунда по сравнению с мыслью о том, что мы что-то забыли проверить, не подумали о важности именно этого теста и пропустили баг в релиз.Можно сказать, что без тест-дизайна мы словно стреляем в цель с закрытии глазами.

Что такое тест-дизайн?

Мы, тестировщики, люди ленивые и не хотим много работать. Даже придумали автоматизированное тестирование, которые выполняет за нас всю нашу работу, а мы в это время лежим на берегу моря ничего не делая и зарабатывая от 100 000 рублей в месяц…. немного отвлекся:) Так вот. Умные люди задумались: а вдруг есть способ не тестировать все страницы? Может быть, есть возможность протестировать сайт быстрее, но так же качественно?

Оказывается есть. Работу тестировщика можно оптимизировать и вместо 1000 тестов провести, например, 15 или 20 тестов. Но для этого необходимо использовать определенные подходы к построению тестов. Такие подходы называют техниками тест-дизайна.

Когда и для чего нужен тест-дизайн:
— когда тестирование включает в себя множество однотипных действий,
— когда необходим вдумчивый подход к тестированию для избежания лишних трат времени и финансов,
— чтобы разработать тесты, которые обнаружат наиболее серьезные ошибки,
— чтобы минимизировать количество необходимых тестов для проверки продукта.

Если брать шире, то тест-дизайн — это процесс который позволяет, используя определенные техники, создать оптимальное тестовое покрытие тестируемого объекта.

Раз речь зашла о процессе, то необходимо проговорить об этапах этого процесса.

Этапы тест-дизайна

Во-первых, необходимо проанализировать тестируемый объект. Изучить его документацию, пообщаться с разработкой, узнать как он работает и как спроектирован. Этап важный, так вы поймете какие техники тест-дизайна использовать. А самое главное — КАК.

Во-вторых, зная информацию о продукте, необходимо определить какие техники необходимо использовать для определенного вида тестирования.

И, в-третьих, используя полученные знания, необходимо составить набор тестов (чек-листов/тест-кейсов)

Изучить продукт. Определить техники. Написать тест-кейсы.

Еще один вопрос: должны ли они идти в таком порядке? Желательно, но не обязательно. Иногда, когда начинаешь писать кейсы, понимаешь, что необходимо еще изучить продукт и снова возвращаешься к первому этапу. Особенно если нет документации. Это нормально.

Техники тест-дизайна

Самый большой интерес в тест-дизайне представляют его техники.

В нашем цикле мы разберем следующие техники на конкретных примерах:
1. Граничные значения и классы эквивалентности.
2. Pairwise.
3. Таблицы переходов.

Кроме знания техник необходимо уметь:
— разделять целый продукт на составные части (декомпозиция),
— находить и анализировать требования к продукту,
— расставлять приоритеты,
— логично излагать свои мысли.

Источник

говориМ о тестировании
простым языком

Обзор техник тест-дизайна

Очень часто мне приходилось сталкиваться с тем, что начинающие тестировщики (да и я сам раньше) путают понятия. Например, исследовательское тестирование — это техника или вид? А функциональное тестирование? Давайте разбираться.

Понятно, что я сам не смогу ответить на этот вопрос, но этого и не нужно. Достаточно обратиться к стандартам и посмотреть, какую же классификацию техник они предлагают. Далеко ходить не стал, посмотрел в сторону ISTQB и вот что получилось.

В первую очередь выделяют три категории методов проектирования тестов:

Методы черного ящика основываются на анализе как требований и спецификаций, так и самого продукта.

Можно сказать, что в этом случае мы подходим к тестированию продукта, как к черному ящику. Мы не знаем, что внутри системы, не видим ее код и архитектуру. Чем-то мы похожи на обычных пользователей, которые видят лишь итог работы команды разработки. Мы тестируем ящик, но не знаем, что находится внутри.

Методы белого ящика являются абсолютной противоположностью методам черного ящика и основываются на анализе архитектуры приложения, внутренней структуры и кода системы.

С помощью этого метода мы заглядываем внутрь объекта тестирования и знаем, как он устроен. Особенностью этих методов является то, что для тестирования не обязательно запускать программу, достаточно взглянуть на исходный код.

Методы, основанные на опыте, используют опыт разработчиков, тестировщиков и пользователей для проектирования, реализации и выполнения тестов. Их часто совмещают с методами черного и белого ящиков.

Итак, если это категории методов, значит они должны включать в себя и сами методы тест-дизайна (проектирования тестов). Давайте посмотрим, какие техники предлагает нам ISTQB.

Методы черного ящика (Black-box Test Techniques)

Методы белого ящика

Методы, основанные на опыте (Experience-based Test Techniques)

Вот и все. Получается не так много, но познавательно. Думаю, это поможет начинающим тестировщикам немного больше понять тестирование и структуру техник тест-дизайна.

Источник

Техники тест-дизайна

Тест-дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

Роли в тест дизайне:

Попросту говоря, задача тест-аналитиков и дизайнеров сводится к тому, чтобы, используя различные стратегии и техники тест-дизайна, создать набор тестовых случаев, обеспечивающий оптимальное тестовое покрытие тестируемого приложения. На большинстве проектов эти роли выполняет QA инженер.

Тестовое покрытие — это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.

Существуют следущее подходы к оценке и измерению тестового покрытия:

Техники тест дизайна:

Пример использования техники анализа классов эквивалентности:

Эквивалентное разделение, алгоритм использования техники:

Можно разбивать тесты на классы эквивалентности по разным принципам. Например, если мы тестируем поле ввода, которое принимает максимум 5 символов, то можем выбрать разные принципы разбиения на классы эквивалентности:

Пример: функцию подсчета комиссии при отмене бронирования авиабилетов. Размер комиссии зависит от времени до вылета, когда совершена отмена:

Рис. 5.1. Пример: функция подсчета комиссии при отмене бронирования авиабилетов

Шаги:

1. Определим классы эквивалентности:

(для каждого теста из этих классов мы ожидаем получить одинаковый результат):

Пример использования техники анализа граничных значений

Примерный алгоритм использования техники анализа граничных значений:

Пример: функцию подсчета комиссии при отмене бронирования авиабилетов. Размер комиссии зависит от времени до вылета, когда совершена отмена:

Рис. 5.2. Пример: функция подсчета комиссии при отмене бронирования авиабилетов

Шаги:

1. Выделим классы эквивалентности:

Источник

Техники тест-дизайна и их предназначение

При создании IT-продукта большую роль играет обеспечение качества – Quality Assurance (QA). Для того, чтобы устранить ошибки и «баги», QA-инженеры в числе прочих инструментов применяют техники тест-дизайна.

Тест-дизайн – это разработка, создание тестов. Каждый тест направлен на проверку конкретного предположения. Например: «Что будет, если пользователь по ошибке кликнет здесь не левой, а правой кнопкой мыши».

QA моделирует набор тестовых случаев (тест-кейсов), чтобы проверить, как приложение ведет себя в разных условиях. Задача специалиста – найти баланс и выявить максимальное количество ошибок при необходимом минимуме тестовых сценариев. При этом нужно проверить все наиболее важные кейсы, поскольку время тестирования ограничено.

Типы тестирования

Статическое тестирование, как следует из названия, не требует запускать программу или приложение и позволяет находить самые очевидные ошибки еще на ранних этапах создания продукта. Например, частью статического тестирования является проверка параметров ПО на соответствие требованиям технического задания, вычитка кода.

Динамическое тестирование требует проверять ПО в действии. Этот вид, в свою очередь, также делится на две обширные группы:

Техники белого ящика (они же структурное тестирование) применяют в том случае, если специалист хорошо знает архитектуру продукта, его код, «начинку» – то есть может ориентироваться в самой программе.

Техники черного ящика позволяют проверять работу продукта, не зная внутреннего устройства системы. При этом тестирование проводится на основе требований, указанных в спецификации проекта или в ТЗ.

Техники серого ящика позволяют тестировать продукт, когда специалист частично знает его внутреннее устройство. Для выполнения тестирования «серого ящика» не нужен доступ к исходному коду.

Этапы тестирования

1. Подготовка. На этом этапе QA-инженер читает проектную документацию, выясняет требования к продукту, прорабатывает план, продумывает стратегию, расставляет задачи по приоритетности и анализирует возможные риски.

2. Непосредственно тестирование. Предварительно специалисты анализируют собранную ранее информацию, составляют список тестируемых функций, знакомятся с уже известными багами, если они есть, пишут тест-кейсы.

Еще раз подчеркнем: принципиально важно стремиться к минимально возможному числу тестов, при этом необходимо, чтобы сценарии находили наибольшее число высокоприоритетных дефектов.

3. Анализ результатов и составление отчетов.

При работе над созданием тестов QA-специалист ориентируется не только на документацию, но и на устные сведения от других QA, аналитиков, разработчиков, менеджеров проекта.

Техники тест-дизайна на примерах

Рассмотрим несколько основных методик, однако, будем помнить, что зачастую их используют в комплексе. Одной техники может быть недостаточно, поскольку она не обеспечит максимальный охват тестовых сценариев.

Эквивалентное разбиение

Метод эквивалентного разбиения позволяет минимизировать число тестов, не создавая сценарий для каждого возможного значения, а выбрав только одно значение из целого класса и приняв за аксиому, что для всех значений в данной группе результат будет аналогичным.

Например, мы тестируем функциональность приложения, позволяющего покупать авиа- и железнодорожные билеты онлайн. Стоимость билета будет зависеть от возраста пассажира, так как дети, студенты и пенсионеры относятся ко льготным категориям.

У нас есть четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно.

QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке.

Граничные значения

Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.

Часто сложности возникают, если возрастные категории указаны «внахлест», например, 0-12, 12-25 лет и т.д.

Таблица принятия решений

Другое название метода – матрица принятия решений. Эта техника подходит для более сложных систем, например – двухфакторной аутентификации. Предположим, чтобы войти в систему, пользователю нужно ввести сначала логин и пароль, а затем еще подтвердить свою личность присланным в смс кодом.

Какие возможны сценарии:
1. Правильный логин и правильный пароль.
2. Правильный логин, неправильный пароль.
3. Неправильный логин, правильный пароль.
4. Неправильный логин, неправильный пароль.

Первый из этих сценариев сопровождается либо правильным, либо неправильным вводом смс-кода, итого у нас получается 5 тестов. При этом только один из сценариев приведет к положительному результату (пользователь успешно авторизуется), а остальные закончатся неудачей.

Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее.

Этот метод хорош тем, что он показывает сразу все возможные сценарии в форме, понятной даже неспециалисту.

Пример таблицы принятия решений

Попарное тестирование

Суть этого метода, также известного как pairwise testing, в том, что каждое значение каждого проверяемого параметра должно быть протестировано на взаимодействие с каждым значением всех остальных параметров. После составления такой матрицы мы убираем тесты, которые дублируют друг друга, оставляя максимальное покрытие при минимальном необходимом наборе сценариев.

Попарное тестирование позволяет обнаружить максимум ошибок без избыточных проверок.

Pairwise testing: пример

Для Parwise достаточно, чтобы каждое значение всех параметров хотя бы единожды сочеталось с другими значениями остальных параметров. Таким образом, матрицу можно значительно сократить. Например:

При составлении матрицы принятия решений для двух браузеров, двух ОС и двух языков было бы нужно 8 сценариев. При попарном тестировании достаточно четырех.

Все это можно просчитать и вручную, но не обязательно – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT). Для проведения тестирования специалист создает текстовый файл с перечислением и их возможных значений, а затем запускает PICT через cmd – командную строку. Скомбинированные тесты отображаются в виде таблицы в самой консоли. Так же результаты по желанию можно выгрузить в файл Excel.

Пример содержимого файла для программы PICT:

Браузер: Chrome, Opera
ОС: Windows, Linux
Язык: RU, ENG

Пример попарного тестирования

Причина и следствие

Простая проверка базовых действий и их результата. Например, если нажать крестик в правом верхнем углу окна (причина), оно закроется (следствие), и т.д. Этот метод позволяет проверить все возможности системы, а также обнаружить баги и улучшить техническую документацию продукта.

Примерный алгоритм использования техники:

1. Выделяем причины и следствия в спецификациях.
2. Связываем причины и следствия.
3. Учитываем «невозможные» сочетания причин и следствий.
4. Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий.
5. Расставляем приоритеты.

Эта техника помогает:

Определить минимальное количество тестов для нахождения максимума ошибок.

Выяснить все причины и следствия – таким образом, мы убедимся, что на любые манипуляции с системой у системы будет ответ.

Найти возможные недочеты в логике описания приложения (что, в свою очередь, поможет улучшить документацию).

Например, QA-специалист тестирует приложение типа “записная книжка”. После ввода всех данных нового контакта и нажатия кнопки Создать (причина) приложение должно автоматически создать карточку с номером телефона, фотографией и ФИО человека (следствие). Тесты покажут, можно ли оставлять одно или несколько полей пустыми, распознает ли система кириллицу, латиницу или оба алфавита, а также другие параметры.

Предугадывание ошибок

Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами.

Например, в спецификации указано, что поле должно принимать код из четырех цифр. В числе возможных тестов:

1. Эта проверка эффективна в качестве дополнения к другим техникам.
2. Выявляет тестовые случаи, которые “никогда не должны случиться”.

Недостатки:
1. Техника в значительной степени основана на интуиции.
2. Необходим опыт в тестировании подобных систем.
3. Малое покрытие тестами.

Итоги

Разумеется, этот список далеко не полон и дает только самое общее представление о принципах тестирования и техниках тест-дизайна. Например, исчерпывающее тестирование, покрывающее все возможные сценарии и обнаруживающее все ошибки, существует только в теории. Это связано с тем, что проверка всех параметров и состояний займет слишком много времени. Однако, чем опытнее QA-специалист, тем лучших результатов он может добиться, и для этого важно уметь правильно подбирать и комбинировать техники.

Источник

Немного о простом. Тест-дизайн. Часть 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 уровень техник тест-дизайна.

В заключении данной статьи скажу, что рассмотренные техники тест-дизайна покрывают только часть проверок для тестирования программы, а именно проверка корректности работы элементов программы и результата их комбинаций в процессе ее работы. Во второй части мы перейдем к техникам тест-дизайна, позволяющим творить чудеса тестирования тестировать логику работы программы и процессы. Это очень важная составляющая ручного тестирования, и именно ее зачастую Вы тестируете на своей работе!

Источник