Метод попарного тестирования
Nov 19, 2018 · 4 min read
Что же такое pairwise testing?
Pairwise testing — техника тест-дизайна, а именно метод обнаружения дефектов с использованием комбинационного метода из двух тестовых случаев. Он основан на наблюдениях о том, что большинство дефектов вызвано взаимодействием не более двух факторов (дефекты, которые возникают при взаимодействии трех и более факторов, как правило менее критичны). Следовательно, выбирается пара двух тестовых параметров, и все возможные пары этих двух параметров отправляются в качестве входных параметров для тестирования. Pairwise testing сокращает общее количество тест-кейсов, тем самым уменьшая время и расходы, затраченные на тестирование. Техника известна уже больше 20 лет, но только последние 5 лет мы можем наблюдать ее активное использование.
Дл я Pairwise testing используют алгоритмы, которые базируются на построении ортогональных матриц, или алгоритмы All-Pairs.
Тестирование с помощью ортогональных матриц
Данная техника тест-дизайна относится к статическим способам тестирование и используется в том случае, когда мы имеем дело с большим количеством входных данных, следовательно, исчерпывающие тестирование является недостижимым. Ортогональные матрицы применяются в конфигурационном, регрессионном, производительном, а так же в тестировании пользовательского интерфейса.
Для того, чтобы построить ортогональную матрицу для этого примера необходимо сделать так, чтобы два любые столбика (в нашем случае это параметры 1, 2 и 3) содержали в себе все возможные комбинации только один раз.
Таким образом, ортогональная матрица для нашего случая будет выглядеть таким образом:
Как мы видим, в столбцах 1 и 3 есть все возможные комбинации: (x,x),(x,y),(y,y),(y,x). Для других пар столбцов это правило работает аналогично.
Тестирование с помощью алгоритма All-Pairs
Аll-pairs testing — комбинаторный метод тестирование программного обеспечения, который проверяет все возможные дискретные комбинации параметров для каждой пары входных параметров системы. Исходя из этого, мы получим меньшее число комбинаций, чем при использовании ортогональных матриц.
Рассмотрим пример. Предположим, нам необходимо протестировать приложение для покупки/продажи б/у ноутбуков, мы имеем следующие переменные:
Если мы захотим протестировать все возможные комбинации, то мы должны составить 2 х 2 х 3 х 2 х 2 х 2 = 96 тест-кейса. Не многовато ли работы для тестирования формы?
Далее нам необходимо организовать переменные и значения.
Т.е. для каждого набора в столбце 1 мы помещаем оба значения столбца 2. То же самое мы повторяем с 3 столбцом.
У нас есть комбинация покупка&Киев и продажа&Харьков, но нету комбинации продажа&Киев и покупка&Харьков. Исправим это, поменяв местами значения во втором наборе третьего столбца.
Повторяем такие же манипуляции для колонок 4 и 5.
Колонка Доставка является более проблематичной, ведь нам не хватает комбинаций на покупка&встреча и продажа&почтой чтобы не нарушать отсортированные данные, нужно ввести еще 2 тестовых случая для этих комбинаций. Значком тильды “
” мы маркируем переменные, которые выступают произвольными. Таким образом мы получаем следующую таблицу.
Таким образом, мы получили готовые 8 тест-кейсов вместо 96.
Утилиты для автоматизации pairwise testing
Существует ряд ПО, которые помогут вам не только качественно, но и быстро создать тест-кейсы из большого количества параметров, самые популярные из них:
Заключение
Суммируя все вышесказанное, pairwise testing — прекрасный метод для повышения эффективности написания тест-кейсов. Он значительно сокращает количество комбинаций, которые будут покрыты, но остается очень хорошим с точки зрения обнаружения неисправностей. Метод очень прост в использовании, для его эксплуатации достаточно лишь определиться с функционалом для проверки, исследовать выбранный сценарий и его параметры и применить алгоритм, который определит оптимальное число тестов с полным перебором пар.
говориМ о тестировании
простым языком
Тест-дизайн. Техника попарного тестирования
Как быть в ситуации, когда необходимо не просто протестировать продукт, а продукт с множеством взаимосвязанных входных данных? Здесь нам на помощь опять приходит тест-дизайн.
Сегодня мы поговорим об еще одной технике составления тестов — техника попарного тестирования (не путать с парным тестированием) или, как ее еще называют, Pairwise testing.
Эта техника используется, когда нам необходимо комбинировать очень много различный вариантов входных данных. Цель ее состоит в том, чтобы сократить количество полученных тестов, но при этом сохранить качественное покрытие.
По традиции приведу определение из ISTQB:
Попарное тестирование (pairwise testing) — разработка тестов методом черного ящика, в которой тестовые сценарии разрабатываются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.
Ее стоит использовать в том случае, когда входные данные связаны друг с другом. Точнее результат выполнения теста напрямую зависит от того, какие комбинации данных будут подаваться на входе.
Рассмотрим очень простой пример. Предположим, у нас есть форма с полями “Логин”, “Пароль” и кнопкой “Войти”.
Каждое поле может принимать два значения: пустое и заполненное. В обычной ситуации, когда результат работы формы не зависит от того, какие именно комбинации полей подаются на вход, нам достаточно провести всего три теста
Т.е. мы в наших тестах проверяем отдельно работу каждого поля, не задумываясь о том, что различные комбинации Логина/Пароля могут сломать систему. Но что, если у нас добавляется еще и зависимость полей? Тогда нам необходимо рассмотреть все возможные комбинации значений между полей. Для нашего примера это означает, что добавится еще один тест.
На первый взгляд выглядит достаточно просто, добавился всего один тест. Но давайте посмотрим на более реальном примере.
Опять же, даже здесь немного упростим проверку и выделим только самые базовые значения.
Таким образом общее количество тестов будет следующим: 2*2*2*2*2*2 = 64
Даже сейчас это большая цифра. Такое тестирование будет малоэффективным и потребует большое количество ресурсов. Вот здесь на помощь приходит техника попарного тестирования, которая позволяет сократить количество тестов во много раз.
Суть ее состоит в том, что мы берем только комбинации пар каждых значений, вместо комбинаций всех значений:
Вручную комбинировать каждую пару нет необходимости. Существуют программы, которые позволяют это сделать автоматически, достаточно только указать параметры и значения. Например, PICT, либо онлайн генераторы https://pairwise.teremokgames.com и т.д.
В нашем случае, после комбинации тестов с помощью попарного тестирования мы сократили количество проверок до 4-х
В каждом тесте мы проверяем сразу несколько пар комбинаций: E-mail — Никнейм, Никнейм — Пароль, Условия — Символы, E-mail — Пароль и т.д.
Подведем итог. Если мы столкнулись с тестированием механики, которая предусматривает различные комбинации входных данных, то в сокращении числа тестов нам как раз и поможет техника попарного тестирования.
И не забывайте пользоваться программами, которые избавят вас от ручного комбинирования.
На что направлено попарное тестирование
Что пишут в блогах
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Где: Кострома / онлайн
2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Если в качестве инструмента у вас имеется лишь молоток, каждая проблема начинает напоминать гвоздь. Абрахам Маслоу
В этой небольшой заметке я бы хотел рассмотреть инструмент для попарного тестирования от Microsoft – PICT (Pairwise Independent Combinatorial Testing). Уже несколько раз я применял его в своей работе и был доволен теми гибкими опциями, которые он имеет.
Для начала неплохо вспомнить, что такое Pairwise Testing. Есть интересная статья про парное тестирование на MSDN. Также про это можно почитать тут. Вкратце, Pairwise testing – это техника формирования наборов тестовых данных. Заключается она в следующем: формируются такие наборы данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров. Предыдущее предложение может быть не совсем понятным, но принцип можно легко проиллюстрировать на следующем примере. Представим, что у нас есть параметры A, B и C принимающие значения Yes или No. Максимальное количество комбинаций значений этих параметров – 8. Но при использовании попарного тестирования достаточно четырех комбинаций, так как учитываются все возможные пары параметров (пара A и B, пара B и C, пара A и C):
Эту технику полезно применять тогда, когда нам не нужны все возможные сочетания значений параметров (особенно когда параметров много), а мы хотим только убедиться, что мы проверим все уникальные пары значений параметров.
Так что же PICT? PICT позволяет генерировать компактный набор значений тестовых параметров, который представляет собой все тестовые сценарии для всестороннего комбинаторного покрытия ваших параметров. К примеру представим, что у нас есть следующие параметры для тестирования (параметры относятся к тестированию создания разделов на жестком диске и взят из мануала к PICT):
Существует больше 4700 комбинаций этих значений. Будет очень сложно протестировать из за разумное время. Исследования показывают, что тестирование всех пар возможных значений обеспечивает очень хорошее покрытие и количество тест кейсов остается в пределах разумного. К примеру, это одна пара и другая; один тест кейс может покрывать много пар. Для набора приведенных выше параметров PICT создаст всего 60 тест кейсов (сравните с цифрой 4700!).
Рассмотрим работу с программой. Запускается PICT из командной строки.
На вход программа принимает простой текстовый файл с параметрами и их значениями, называемый Моделью, а на выход выдает сгенерированные тестовые сценарии.
Рассмотрим работу программы на примере из приведенной выше статьи из блога. Имеем следующие параметры и их значения: пол – мужской или женский; возраст – до 25, от 25 до 60, более 60; наличие детей – да или нет. Если перебирать все возможные значения, то количество сценариев будет 12. Составим модель и посмотрим какой результат нам выдаст программа.
Используем модель и получим 7 тестовых сценариев (вместо 12):
Разница не такая ощутимая, но она будет становится все более и более заметной при увеличении количества параметров или их значений.
Можно использовать прямой вывод и сохранение тест кейсов в Excel.
В результате будет создан Excel файл со следующим содержанием:
Но самое интересное это те возможности, которые предоставляет PICT для подобной генерации сценариев. Все они тщательно рассмотрены в мануале. Вот некоторые из них:
На что направлено попарное тестирование
Что пишут в блогах
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Где: Кострома / онлайн
2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Каждый тестировщик пишет тесты по определенному принципу. Даже тот, кто слыхом не слыхал ни о каких методиках, так или иначе руководствуется рядом принципов, которые, как правило, держит в голове, или в редких случаях на бумаге. Но скажите, какой бывалый тестировщик не представлял себе фантастическую ситуацию, когда эти принципы реализованы в коде: софт создает тест-кейсы. Конечно до такой радужной перспективы еще очень далеко, но первые шаги на этом поприще уже сделаны…
Описание метода
Представьте себе, что вам нужно протестировать систему с большим числом параметров, влияющих на её работу. Ярким примером такого рода может быть конфигурационное тестирование: например проверка работы системы под различными операционными системами или работа сайта в различных браузерах. Кто знает, какое сочетание параметров приведет к сбою? Каждый тестировщик знает, что все комбинации не проверить. К примеру, для проверки всех сочетаний 10 параметров с 10 значениями каждый, потребуется 10,000,000,000 тестов, в то время как метод перебора пар позволяет реализовать сравнимое по качеству тестирование (учитывая количество и критичность найденных в результате багов) используя всего 177 тестов.
Итак, в чем же трюк? Метод парного тестирования основан на довольно простой, но от того не менее эффективной идее, что подавляющее большинство багов выявляется тестом, проверяющим один параметр, либо сочетание двух. Ошибки, причиной которых явились комбинации трех и более параметров как правило значительно менее критичны, чем пары параметров и тем более одного, не говоря уже о том что никто не мешает дополнить свое тестовое покрытие кейсами на желаемые комбинации параметров.
Перебрать все пары немудрено, трудность в том, чтобы обеспечить при этом минимум тестов, комбинируя проверки нескольких пар в одном тесте. Тут нам на помощь приходят математические методы, уходящие корнями к английским математикам девятнадцатого века. Одним из плодов их трудов стали ортогональные матрицы. Я лишь упоминаю их вскользь, дабы любители линейной алгебры могли навести справки, благо информации в интернете предостаточно. Что важно нам, так это то, что велосипед изобретать не нужно, и методы, по которым мы можем сформировать оптимальное покрытие, давно изобретены.
Рассмотрим как происходит оптимизация. Возьмем для примера таблицу параметров и значений следующего вида:
Переберем значения первого параметра со вторым (строки №1-4), первого с третьим (строки №5-8) и второго с третьим (строки №9-12). Удалив повторяющиеся наборы параметров (выделены серым), получим следующую таблицу тестов:
Зеленым выделены уникальные пары всех параметров в таблице. Теперь начинается самое интересное, значения выделенные белым не являются необходимыми для перебора всех пар в таблице, поэтому могут быть заменены на любое другое значение. Поэтому заменив их, мы можем оптимизировать тесты, добавив проверку пар из 5, 6 и 7 строк во вторую и третью строки, получим:
Как видно из примера выше, оптимизация даже такого малого набора параметров не так проста как могло бы показаться. При этом сложность задачи возрастает пропорционально росту числа параметров. Однако эта задача решаема, в чем мы убедимся в последствии.
Применение
Как показывает опыт, метод эффективен лишь на поздних этапах разработки, либо дополненный основными функциональными тестами. Например, если вы проводите конфигурационное тестирование, то прежде чем использовать парное тестирование следует убедиться, что основной сценарий функционирует на всех операционных системах с параметрами по умолчанию (что-то типа BVT). Это значительно облегчит локализацию будущих багов, ведь при парном тестировании в одном тесте фигурирует множество параметров со значениями не по умолчанию, каждый из которых может стать причиной сбоя и его локализация в этом случае весьма затруднительна. А в случае провала BVT следует отказаться от использования метода парного тестирования, так как многие тесты будут провальными, а исключение даже одного теста влечет за собой потерю как правило нескольких пар и смысл использования метода теряется.
Поэтому метод следует использовать лишь на стабильном функционале, когда текущие тесты уже теряют свою эффективность.
Для того чтобы воспользоваться методом необходимо выполнить несколько простых шагов:
1. Определиться с функциональностью, которую будем проверять
Как говаривал Козьма Прутков «Нельзя объять необъятное», поэтому прежде всего необходимо разделить функциональность на части: компоненты, функции, сценарии. Функциональность небольшой программы, например по записи дисков, упрощенно можно представить в виде всего двух сценариев: запись диска, стирание диска. Выбираем запись диска и переходим к следующему шагу.
2. Исследовать выбранный сценарий и выявить его параметры и их значения
На данном этапе следуют спросить себя, какие параметры сценария могут повлиять на его выполнение? В качестве параметров могут выступать как настройки самой программы, так и внешние факторы.
Упрощенно, параметры и их значения при записи диска можно представить в виде:
Вы наверняка обратили внимание, что параметр «Скорость записи» имеет значения, недопустимые для “DVD”, как же быть?. У этой маленькой задачки, есть несколько вариантов решения, одно из которых – это разделить таблицу на две. Стоит учитывать, что на практике параметров в этом сценарии гораздо больше, и несостыковок, было бы значительно больше.
Итак, поделив таблицу по типу носителя получим:
Меньше, чем пара. Еще один способ сокращения количества тестов
Любому QA известен такой метод минимизации тест-кейсов, как Pairwise Testing — попарное тестирование. Метод отличный, достаточно простой и проверенный множеством команд. Но что делать, если после его применения кейсов остается слишком много?
Именно так произошло в моем проекте, и сегодня я расскажу, как можно еще сильнее сократить количество тест-кейсов, не теряя при этом в качестве.
Тестируемый объект
Для начала расскажу немного о продукте. В Тинькофф наша команда разрабатывала блоки — это React-компоненты, состоящие из реализации и конфигурации. Реализация — это непосредственно сам компонент, который мы разработали и который видит пользователь в браузере. Конфигурация — это JSON, который задает параметры и наполнение этого объекта.
Главная задача блоков — быть красивыми и одинаково отображаться у разных пользователей. При этом от конфигурации и контента блок может очень значительно меняться.
Например, блок может быть таким — без фона, с кнопкой и картинкой справа:
Или вот таким — с фоном, без кнопки и с картинкой слева:
Или вообще вот таким — со ссылкой вместо кнопки и без списка в тексте:
Все примеры выше — это один и тот же блок, который имеет одну версию конфигурации (структура JSON, которую умеет обрабатывать конкретно этот React-компонент), но разное ее наполнение.
Кейсы из сочетания параметров
В этой статье я не буду касаться вопросов версионирования схемы блоков, правил наполнения контентом или того, откуда в блок приходят данные. Все это — отдельные темы, которые никак не влияют на составление набора тест-кейсов. Главное, знать: у нас есть много параметров, влияющих на наш компонент, и каждый из них может принимать свой набор значений.
Для примера выше я выбрала блок с достаточно простой конфигурацией. Но даже в нем проверка всех сочетаний значений всех параметров займет непозволительно много времени, особенно если придется учитывать кроссбраузерность. Обычно здесь на помощь приходит Pairwise Testing, или попарное тестирование. Про него уже написаны тонны статей и есть даже обучения. Если вдруг не сталкивались — обязательно почитайте.
Давайте прикинем, сколько тест-кейсов у нас получится при его применении. Мы имеем больше 25 параметров, и некоторые из них принимают аж 7 и 9 вариантов значений. Да, можно чем-то пренебречь: например, если вы проверяете верстку, guid вам не важен. Но при применении Pairwise Testing все равно получится больше 80 тест-кейсов. И это, как я уже писала, для не самого сложного блока и без учета кроссбраузерности. Блоков у нас сейчас больше 150, и их количество растет, так что позволить себе столько кейсов мы не можем, если хотим сохранить скорость тестирования и выпуска новых версий.
Кейсы из одного параметра
Метод попарного тестирования основан на утверждении о том, что большинство дефектов вызвано взаимодействием не более двух факторов. То есть большинство багов проявляются либо на одном значении какого-то параметра, либо на сочетании значений двух параметров. Мы решили пренебречь второй частью этого утверждения и предположили, что при проверке одного параметра все равно будет найдено большинство багов.
Тогда получается, что для тестирования нам нужно проверить каждое значение каждого параметра хотя бы один раз. Но при этом каждый блок несет в себе всю конфигурацию. Тогда можно в каждом новом кейсе проверять максимум еще не проверенных значений, чтобы минимизировать количество кейсов.
Разберем алгоритм построения кейсов на упрощенном примере. Возьмем из нашей схемы компонент button и составим для него тест-кейсы:
Шаг 1. Составляем варианты контента для каждого поля
Здесь, на мой взгляд, важно очень четко определить границы и функциональность своей системы и не проверять лишнее. То есть если проверка на обязательность ключей или валидация значения реализованы в сторонней системе, то и проверять эту функциональность нужно в сторонней системе. А мы должны в качестве кейсов использовать только «правильные» данные.
По большому счету этот же принцип используется в пирамиде тестирования. При желании самые критичные интеграционные тесты можно добавить к нам — например, проверять обработку не пришедшего ключа. Но таких тестов должно быть минимальное количество. Иной подход — стремление к исчерпывающему тестированию, которое, как всем известно, невозможно.
Итак, мы определили варианты контента для каждого поля и составили такую таблицу:
В эту таблицу входит каждый класс эквивалентности каждого параметра, но только один раз.
Вот такие классы значений в нашем случае классы:
Шаг 2. Обогащаем таблицу данными
Поскольку каждый блок несет в себе полную конфигурацию, нам нужно добавить какие-нибудь релевантные данные в пустые ячейки:
Теперь каждый столбец — это один кейс.
При этом, поскольку недостающие данные мы выбираем сами, мы можем генерировать кейсы исходя из приоритета. Например, если мы знаем, что в кнопке короткий текст используется чаще, чем текст средней длины, то и проверять его стоит чаще.
В примере выше также можно обратить внимание на «выпавшие» кейсы — кейсы, в которых какой-то параметр вообще не проверяется, хотя и присутствует в таблице. В данном случае button.color.style: secondary не будет проверен на внешний вид, потому что неважно, какой стиль у отключенной кнопки.
Чтобы «выпавшие» кейсы не привели к багам, раньше мы анализировали полученные наборы значений. Анализ происходил один раз при генерации тестовых наборов, и все «выпавшие» кейсы добавлялись вручную в итоговый тестовый набор. Такое решение проблемы достаточно топорное, но дешевое (если, конечно, у вас редко меняются конфигурации тестируемых объектов).
Более универсальное решение — разделить все значения на две группы:
Шаг 3. Уточняем значения
Теперь осталось только сгенерировать конкретные значения вместо классов эквивалентности.
Здесь каждому проекту придется подобрать свои варианты значений, опираясь на особенности тестируемого объекта. Некоторые значения генерировать очень просто. Например, цвет для большинства полей можно просто брать любой. Для некоторых блоков при проверке цвета приходится добавлять градиент, но он вынесен в отдельный класс эквивалентности.
С текстом чуть сложнее: если сгенерировать строку из случайных символов, то не будут протестированы переносы, списки, теги, неразрывные пробелы. Мы генерируем короткие и средней длины строки из реального текста, обрезая его до нужного количества символов. А в длинном тексте проверяем:
Получается, что для каждого проекта нужно составить свой актуальный набор контента исходя из реализации тестируемого объекта.
Алгоритм
Конечно, на первый взгляд может показаться, что алгоритм сложный и не стоит потраченных усилий. Но если опустить все детали и исключения, которые я постаралась описать в каждом пункте выше, получается достаточно просто.
Шаг 1. Добавляем в таблицу параметров все возможные значения:
Шаг 2. Дублируем значения в пустые ячейки:
Шаг 3. Превращаем абстрактные значения в конкретные и получаем кейсы:
Каждый столбец таблицы — это один кейс.
Преимущества подхода
Такой способ генерации тест-кейсов имеет несколько важных преимуществ.
Меньше кейсов
Первое и очевидное — кейсов значительно меньше, чем в попарном тестировании. Если брать упрощенный пример с кнопкой — у нас получилось 4 кейса вместо 8 в попарном тестировании.
Чем больше параметров в тестируемом объекте, тем значительнее будет экономия кейсов. Например, для полного блока, представленного в начале статьи, у нас получается 11 кейсов, а с помощью попарного — 260.
Не раздувается количество кейсов при усложнении функциональности
Второй плюс — при появлении новых параметров, учитывающихся при тестировании, количество кейсов увеличивается далеко не всегда.
Количество кейсов увеличится только в том случае, если у какого-то параметра станет больше значений, чем было кейсов.
Можно чаще проверять важное
За счет обогащения значениями (шаг 2 в алгоритме) можно чаще проверять более приоритетные или более рискованные значения.
Например, если мы знаем, что раньше пользователи чаще использовали короткий текст, а теперь — более длинный, мы можем обогащать кейсы более длинным текстом и чаще попадать в реальные пользовательские кейсы.
Можно автоматизировать
Алгоритм, приведенный выше, вполне поддается автоматизации. Конечно, сгенерированные алгоритмом кейсы будут меньше походить на реальные, чем сгенерированные человеком. Хотя бы за счет подбора цветов и обрезания текста.
Но зато уже в процессе разработки без участия тестировщика появляются кейсы, что очень сильно сокращает петлю обратной связи.
Недостатки
Естественно, такая генерация кейсов — далеко не серебряная пуля и имеет свои недостатки.
Сложно анализировать результат
Думаю, вы обратили внимание, что в процессе генерации кейсов происходит смешивание тестовых данных друг с другом. Из-за этого при падении кейса усложняется процесс выявления причины падения. Ведь часть параметров, задействованных в кейсе, никак не влияет на результат теста.
Это правда затрудняет разбор результатов тестов, с одной стороны. Но, с другой стороны, если тестируемый объект требует большой объем обязательных параметров, это тоже затрудняет нахождение причины бага.
Могут быть пропущены баги
Возвращаясь к самому началу статьи: при применении этого метода мы допускаем возможность пропуска багов, вызванных сочетанием двух и более параметров. Зато выигрываем в скорости, так что только вам решать, что важнее на каждом конкретном проекте.
Чтобы не пропускать баги дважды, мы ввели Zero Bug Policy и стали закрывать каждый пропущенный баг дополнительным тест-кейсом — уже не автоматически сгенерированным, а написанным вручную. Это дало отличные результаты: сейчас у нас более 150 блоков (тестируемых объектов), несколько релизов в день и от 0 до 3 пропущенных некритичных багов в месяц.
Выводы
Если в вашем тестируемом объекте широкий набор входных параметров и вы хотите попробовать сократить количество кейсов и, как следствие, время на тестирование, я рекомендую попробовать приведенный выше метод генерации кейсов через один параметр.
На мой взгляд, для фронтовых компонентов он подходит идеально: можно более чем в три раза сократить время, например, на проверку внешнего вида через скриншот-тестирование. Да и разработка пойдет быстрее за счет появления кейсов на самых ранних этапах.
Конечно, если вы тестируете автопилот новой «Теслы» — нельзя пренебрегать даже малой вероятностью пропуска бага. Но в большинстве случаев не стоит забывать, что скорость в современном мире — это весьма важный критерий качества. А прирост скорости дает больше положительного результата, чем пара найденных минорных проблем.
А для самых ответственных в следующей статье я расскажу, как можно дополнительно предохраниться от хитрых багов, вызванных сочетанием параметров, при помощи пользовательских кейсов и StoryBook.
