какие тесты считаются эквивалентными
Какие тесты считаются эквивалентными
Что пишут в блогах
Продолжу хвастаться статусом книги.
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Introduction
Разделы портала
Про инструменты
Автор: Джеймс Бах (James Bach)
Перевод: Ольга Алифанова
Статья в Википедии о классах эквивалентности – это отличный пример бедности мышления, обучения и письма, который часто прокатывает за мудрость в кругах тестировщиков. Это узкое, неверно направляющее людей определение, подразумевающее, что тестирование – это такая игра, в которую мы играем с ПО, а не открытое исследование сложного феномена.
(Нет, я не буду редактировать эту статью в википедии. Я не считаю забавным или полезным предлагать свой опыт в обмен на аргументы анонимных любителей. Википедия очень важна, потому что служит всеобщей справкой, если нужно покритиковать популярное знание, но как и само популярное знание, она неисправима. Популярное всегда побеждает, а народ не особо любит размышлять).
В этой статье я прокомментирую одну часть статьи в Википедии. В следующей статье я опишу классы эквивалентности так, как вижу их я, и вы сами сможете решить, чье определение лучше – мое или Википедии.
«Классы эквивалентности – это техника тестирования ПО, которая делит вводимые данные на классы эквивалентных друг другу значений, на базе которых создаются тест-кейсы».
Не совсем. Нет никаких оснований полагать, что классы эквивалентности ограничиваются «вводимыми данными». Мыслительный процесс деления на классы эквивалентности может применяться к выходным данным, версиям продукта, тестовым окружениям, или кейсам как таковым. Классы эквивалентности применимы к чему угодно, где вариативность может повлиять на результат теста.
Да, это техника, но более подходящим словом будет «эвристика». Эвристика – это ненадежный метод решения проблемы. Классы эквивалентности крайне ненадежны, но меж тем полезны.
«В принципе, тест-кейсы пишутся так, чтобы покрыть каждый класс хотя бы один раз. Эта техника пытается определить тест-кейсы, выявляющие классы ошибок, снижая тем самым общее количество необходимых для работы тест-кейсов».
Этот текст достаточно неплох. Отметьте выражение «в принципе» и использование слова «пытается». Это смягчающие слова, и это важно, потому что классы эквивалентности – эвристика, а не алгоритм.
Говорить, меж тем, о «кейсах, которые необходимы для работы» – это уводить разговор в сторону от тестирования. Тестирование – это не создание тест-кейсов, и это точно не про количество тест-кейсов, которые вы создаете. Тестирование – это проведение экспериментов, а общее количество экспериментов выходит далеко за рамки вопросов вроде «какой тест-кейс мне написать далее?». Эта фраза должна звучать как «снижая тестовые усилия».
«Преимущество этого подхода – это сокращение времени, требуемого на тестирование ПО благодаря меньшему количеству тест-кейсов».
Извините, но нет. Преимущество классов эквивалентности вовсе не в снижении количества тест-кейсов. Это даже не о снижении тестовых усилий как таковых (хотя верно, что эта техника «пытается» снизить усилия по тестированию»). Классы эквивалентности – это просто способ систематически угадывать, где, возможно, скрываются самые крупные баги, и помогающая фокусировать ваши усилия. Классы эквивалентности – это техника приоритезации. Она помогает вам объяснять свой выбор и защищать его. Лучшая приоритезация сама по себе не снижает усилия по тестированию, но ее цель – наткнуться на крупные баги раньше, а не позже. И мы хотим наткнуться на них целенаправленно, а не случайно. И если мы хорошо сделали свою работу, то да, мы потратим меньше усилий на тестирование. Снижение тестовых усилий – побочный эффект техники классов эквивалентности.
«Классы эквивалентности обычно применяются к данным, вводимым в тестовый компонент, но могут применяться и к выходным данным в редких случаях. Как правило, они вытекают из требований или спецификации для ввода данных, влияющих на обработку тестового объекта».
Обычно? Как правило? Автор провел некое исследование, подтверждающее это? Нет.
Классы эквивалентности – это процесс, которым все мы неформально занимаемся, не только в тестировании, но и в повседневной жизни. Когда вы открываете дверь – вы сознательно решаете толкнуть именно этот квадратный сантиметр металлической доски? Нет, вовсе нет. Вы знаете, что для большинства дверей совершенно не важно, куда их толкают. Все места, которые можно толкнуть, эквивалентны. Это класс эквивалентности! Мы применяем классы эквивалентности ко всему, с чем мы взаимодействуем.
Да, мы применяем эту технику к выходным данным и да, мы можем рассматривать классы эквивалентности, основанные на спецификации, но мы также рассматриваем классы, основанные на том, что мы изучили о тестируемом ПО. Мы применяем классы эквивалентности, основываясь на всем, что мы знаем. Если то, что мы знаем, неверно (к примеру, если в ПО есть неожиданные баги), то наши классы эквивалентности тоже будут неверны. И это нормально, если вы понимаете, что это эвристика, а не золотой билет в страну идеального тестирования.
«Фундаментальная концепция классов эквивалентности исходит из отношения эквивалентности. Программная система – это, по сути, расчетная функция, внедренная как алгоритм на некоем языке программирования. Если заданы входные данные, некоторые инструкции этого алгоритма покрываются (см. «Покрытие кода»), а некоторые – нет…»
На этом моменте статья превращается в пропаганду информатики. Вот почему в тестировании так мало хороших вещей: как только туда приходят информатики, они превращают его в маленькую логическую игру для одаренных детей, а не в занятие для взрослых людей, нацеленное на поиск важных проблем в технологии до того, как будет слишком поздно.
Фундаментальная концепция классов эквивалентности не имеет ничего общего с информатикой или расчетами. Она про логику. Логика существовала задолго до компьютеров. Класс эквивалентности – это, грубо говоря, набор. Это набор вещей, разделяющих определенное свойство. Интересное с точки зрения класса эквивалентности свойства – это полезность для исследования специфического риска продукта. Иными словами, тестирование классов эквивалентности – это убеждение, что каждый член определенной группы вещей будет с более или менее равной вероятностью находить определенный вид бага, если его применить в определенном виде теста.
Если я определю «тестовые условия» как нечто о продукте или его окружении, что может быть исследовано при тестировании, то я могу определить классы эквивалентности примерно так: Класс эквивалентности – это набор тестов или тестовых условий, которые эквивалентны по отношению к определенному продуктовому риску в определенном контексте.
Это определение подразумевает, что два вида данных, которые не эквивалентны для одного бага, могут быть эквивалентны для поиска другого бага. Это также подразумевает, что если мы неверно смоделировали продукт, мы не узнаем правильные классы эквивалентности. В целом, учитывая, что баги бывают всех размеров и сортов, выделить идеально верные классы эквивалентности – это примерно как заранее, без тестирования, знать, где находятся баги в продукте. Это связано с тем, что классы эквивалентности основаны на догадках, какие типы багов могут встретиться в продукте.
Если вы читали техническую часть про информатику в статье Википедии, вы видели, что авторы решили, что два вида данных, покрывающих один и тот же код, эквивалентны для целей поиска багов. Это совсем, совсем не так! Это фантазия, которую продвигают люди, которые, как я подозреваю, в жизни ничего важного не тестировали. Сходу могу сказать, что покрытие кода как золотой стандарт игнорирует баги производительности, баги требований, баги удобства использования, баги данных, баги безопасности и баги интеграции. Представьте себе два теста, покрывающих один и тот же код и включающих отображаемые на экране данные. В одном тесте ввод настолько длинный, что при печати на экране он выходит за его границы. Это баг, который не будет найден при коротком вводе, хотя оба вида данных «валидны» и функционально «делают одно и то же».
Основная проблема с большинством советов по тестированию
Проблема с большинством советов по тестированию заключается в том, что это или некритично подобранный фольклор, который разлетается в пыль, как только вы как следует изучите его, или это примененный бесцельно формализм, который нельзя прилагать к реалистичным открытым проблемам. Советы по тестированию куда лучше звучат, когда они базируются на перспективе общих систем и социальных наук. Обе эти перспективы понимают и используют эвристики. Классы эквивалентности – это мощная, широко распространенная и довольно простая эвристика, чья полезность проистекает из вашей ментальной модели продукта и ограничена ей же. В моей следующей статье я приведу пример использования этой эвристики в реальной жизни.
Техники тест-дизайна
Тест-дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Роли в тест дизайне:
Попросту говоря, задача тест-аналитиков и дизайнеров сводится к тому, чтобы, используя различные стратегии и техники тест-дизайна, создать набор тестовых случаев, обеспечивающий оптимальное тестовое покрытие тестируемого приложения. На большинстве проектов эти роли выполняет QA инженер.
Тестовое покрытие — это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.
Существуют следущее подходы к оценке и измерению тестового покрытия:
Техники тест дизайна:
Пример использования техники анализа классов эквивалентности:
Эквивалентное разделение, алгоритм использования техники:
Можно разбивать тесты на классы эквивалентности по разным принципам. Например, если мы тестируем поле ввода, которое принимает максимум 5 символов, то можем выбрать разные принципы разбиения на классы эквивалентности:
Пример: функцию подсчета комиссии при отмене бронирования авиабилетов. Размер комиссии зависит от времени до вылета, когда совершена отмена:
Рис. 5.1. Пример: функция подсчета комиссии при отмене бронирования авиабилетов
Шаги:
1. Определим классы эквивалентности:
(для каждого теста из этих классов мы ожидаем получить одинаковый результат):
Пример использования техники анализа граничных значений
Примерный алгоритм использования техники анализа граничных значений:
Пример: функцию подсчета комиссии при отмене бронирования авиабилетов. Размер комиссии зависит от времени до вылета, когда совершена отмена:
Рис. 5.2. Пример: функция подсчета комиссии при отмене бронирования авиабилетов
Шаги:
1. Выделим классы эквивалентности:
говориМ о тестировании
простым языком
Тест-дизайн. Классы эквивалентности и граничные значения
В этой статье мы разберем одну из самых известных и фундаментальных техник, технику выделения классов эквивалентности и граничных значений.
В чем суть техники?
Основная задача определения классов эквивалентности и граничных значений — «уйти» от дублирующих проверок. Таким образом, мы сократим количество однотипных тестов до необходимого минимума. Как это можно представить?
Предположим, у нас много-много разных булок, сделаны они по одному рецепту, а вот форма у них немного разная. А теперь представьте, что вам необходимо определить вкус каждой булки. Что вы будете делать? Попробуете все или возьмете только одну, потому что остальные сделаны аналогично? Я думаю второй вариант будет более оптимальным)
В тестировании ситуация аналогичная. Только вместо булок наши тесты. И все немного сложнее.
Классы эквивалентности
Сначала дадим определение классам эквивалентности.
Эквивалентная область (equivalence partition) —часть области входных или выходных данных, для которой поведение компонента или системы, основываясь на спецификации, считается одинаковым.
Скорей всего было не очень понятно…
Проще говоря, любой тест, выполненный из одного и того же класса эквивалентности, приведет к точно такому же результату, как и выполнение всех остальные тестов из этого же класса.
Например, у нас есть 10 тестов из одного класса. Если один из этих тестов проходит корректно, и то все остальные пройдут корректно. И наоборот, если один из тестов приведет к падению системы, то и все остальные тесты, также приведут к падению.
Пока все еще абстрактно, давайте конкретизируем. Предположим, у нас планируется акция «Скидка 10% на покупку от 5 товаров». Нам необходимо проверить функционал скидки в зависимости от количества товаров. Что будем делать? Есть два варианта проверки:
Тестов получается очень много.
2. Попробовать выделить классы эквивалентности и оптимизировать проверки.
Пойдем по второму варианту, он более эффективный. У нас всего два разных результата выполнения теста – со скидкой и без скидки. Логично предположить, что класса эквивалентности тоже будет два. В одном тесты будут проверять наличие скидки в 10%, в другом ее отсутствие.
Графически это можно представить следующим образом:
Т.е. какой бы мы тест не взяли из первого класса, мы получим скидку в 0%, аналогично для второго класса эквивалентности.
Теперь теория и здравый смысл подсказывают нам, что можно взять не все тесты, а только несколько из каждого класса эквивалентности. Этого должно быть достаточно, чтобы проверить оба случая со скидкой.
Но теперь вопрос, какие тесты брать? Есть ли разница между ними, может быть все-таки есть небольшие отличия?
Граничные значения
Путем долгого времени наблюдения за разработкой и анализа багов, специалисты пришли к выводу, что большинство ошибок возникает именно на границах между классами эквивалентности. Т.е. нам в первую очередь важно проверить переходы на стыке границ каждого класса, так как именно там велик риск возникновения ошибок.
Поэтому для эффективного тестирования нам необходимо выделить у каждого класса граничные значения. Давайте попробуем сделать на нашем примере:
Итого, 4 теста вместо 100 с учетом сохранения тестового покрытия.
Наша задача, как тестировщика, уметь правильно определить и работать с классами эквивалентности и граничными значениями. Выше мы рассмотрели пример с позиции черного ящика. У него есть существенные минус, мы не знаем как реализована работа функционала с точки зрения кода. Следовательно, не можем со 100% уверенностью правильно выделить классы эквивалентности.
Давайте рассмотрим пример посложней. Нам необходимо проверить корректность бокового меню на сайте из 10 страниц. Вот такое:
Страницы сами по себе одинаковые и отличаются только содержанием, боковое меню зрительно полностью идентично.
Только что пройденный материал подсказывает нам, что есть один класс эквивалентности и он включает в себя все 10 страниц. Но на практике есть как минимум два варианта:
1. Если сайт сделан на HTML, в том числе и боковое меню, то необходимо проверять КАЖДУЮ страницу, так как на каждой странице боковое меню работает отдельно от остальных.
2. Если сайт сделан с помощью, например, шаблонизаторов, то тогда выделить 10 страниц в класс эквивалентности можно, так как код меню хранится отдельно.
Т.е. в зависимости от реализации, классы будут разные. Как это определить? Если вы знаете языки программирования и у вас есть доступ в репозиторий, то посмотреть в код. Если вы не поняли, что я сейчас написал, то подойдет и второй вариант) Поговорите с программистом, который делал эту функциональность и уточните у него, правильно ли вы делаете.
Немного о простом. Тест-дизайн. Часть 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 уровень техник тест-дизайна.
В заключении данной статьи скажу, что рассмотренные техники тест-дизайна покрывают только часть проверок для тестирования программы, а именно проверка корректности работы элементов программы и результата их комбинаций в процессе ее работы. Во второй части мы перейдем к техникам тест-дизайна, позволяющим творить чудеса тестирования тестировать логику работы программы и процессы. Это очень важная составляющая ручного тестирования, и именно ее зачастую Вы тестируете на своей работе!