Тест дизайн что это
Тест-дизайн. Когда и для чего
Предположим простую ситуацию. Вам дали тестировать сайт с описанием фильмов. Там около 1000 страниц. Простой вопрос, что тестировать?
Всегда существует вариант — тестировать “в лоб”. Открываем каждую страницу, проверяем на месте ли текст и картинки, смотрим, что расположение элементов не поехало и все стоит на своих местах. Звучит как-то не очень весело, не правда ли? Я уже не говорю о потраченном времени.
Или, например, у нас есть интернет-магазин, в котором около 5000 товаров. Получается, для того, чтобы проверить покупку товаров, нам необходимо зайти в каждый и купить?
Но это еще ерунда по сравнению с мыслью о том, что мы что-то забыли проверить, не подумали о важности именно этого теста и пропустили баг в релиз.Можно сказать, что без тест-дизайна мы словно стреляем в цель с закрытии глазами.
Что такое тест-дизайн?
Мы, тестировщики, люди ленивые и не хотим много работать. Даже придумали автоматизированное тестирование, которые выполняет за нас всю нашу работу, а мы в это время лежим на берегу моря ничего не делая и зарабатывая от 100 000 рублей в месяц…. немного отвлекся:) Так вот. Умные люди задумались: а вдруг есть способ не тестировать все страницы? Может быть, есть возможность протестировать сайт быстрее, но так же качественно?
Оказывается есть. Работу тестировщика можно оптимизировать и вместо 1000 тестов провести, например, 15 или 20 тестов. Но для этого необходимо использовать определенные подходы к построению тестов. Такие подходы называют техниками тест-дизайна.
Когда и для чего нужен тест-дизайн:
— когда тестирование включает в себя множество однотипных действий,
— когда необходим вдумчивый подход к тестированию для избежания лишних трат времени и финансов,
— чтобы разработать тесты, которые обнаружат наиболее серьезные ошибки,
— чтобы минимизировать количество необходимых тестов для проверки продукта.
Если брать шире, то тест-дизайн — это процесс который позволяет, используя определенные техники, создать оптимальное тестовое покрытие тестируемого объекта.
Раз речь зашла о процессе, то необходимо проговорить об этапах этого процесса.
Этапы тест-дизайна
Во-первых, необходимо проанализировать тестируемый объект. Изучить его документацию, пообщаться с разработкой, узнать как он работает и как спроектирован. Этап важный, так вы поймете какие техники тест-дизайна использовать. А самое главное — КАК.
Во-вторых, зная информацию о продукте, необходимо определить какие техники необходимо использовать для определенного вида тестирования.
И, в-третьих, используя полученные знания, необходимо составить набор тестов (чек-листов/тест-кейсов)
Изучить продукт. Определить техники. Написать тест-кейсы.
Еще один вопрос: должны ли они идти в таком порядке? Желательно, но не обязательно. Иногда, когда начинаешь писать кейсы, понимаешь, что необходимо еще изучить продукт и снова возвращаешься к первому этапу. Особенно если нет документации. Это нормально.
Техники тест-дизайна
Самый большой интерес в тест-дизайне представляют его техники.
В нашем цикле мы разберем следующие техники на конкретных примерах:
1. Граничные значения и классы эквивалентности.
2. Pairwise.
3. Таблицы переходов.
Кроме знания техник необходимо уметь:
— разделять целый продукт на составные части (декомпозиция),
— находить и анализировать требования к продукту,
— расставлять приоритеты,
— логично излагать свои мысли.
Процесс тестирования. Часть 2: Анализ тестирования и тест дизайн
Благодаря плану и стратегии тестирования, мы можем легко понять, какие компаненты нам надо тестировать и какие виды\методы\техники нам нужно применить. Но при этом, часто тестировщик сталкивается с проблемами непонимания того, насколько глубоко нужно тестировать конкретное требование. Помимо этого, не очень понятно как эффективнее всего будет проверить то или иное условие. При хорошем процессе тестирования, на все эти вопросы отвечают процессы анализа тестирования и тест дизайна.
Если вы не знакомы с фундаментальным процессом тестирования, то рекомендуем начать с первой части:
Анализ тестирования и тест дизайн
Анализ тестирования (Test analysis) — это активность, которая определяет, что должно быть протестировано.
Проектирование тестов (тест дизайн, Test design) — это активность, которая определяет, как должно быть протестировано то, что было определено в рамках анализа тестирования.
Очень часто эти 2 процесса выполняются одновременно. Но сегодня мы разберём детально, что именно должно происходить на каждом из этапов.
Для этих двух активностей необходим анализ базиса тестирования.
Базис тестирования (Test basis) — документ, на основании которого определяются требования к
компоненту или системе. То есть документация, на которой базируются тестовые сценарии.
Базисом тестирования может быть представлен в следующем виде: Спецификаций (Specifications), Концепции (Vision), Варианта использования (Use-case), Истории использования (User story), Макет (Mockup), Прототип (Prototype) и тд.
Разберём немного подробнее этап анализа тестирования
Анализ тестирования
Представим, что мы тестируем интернет-магазин. Исходя из требований (базиса тестирования) мы понимаем, что именно нам нужно протестировать. Например, нам надо проверить, что пользователь может зарегистрироваться, войти в приложение, найти там товар, добавить его в корзину, после чего оплатить и получить.
Дальше, в рамках анализа тестирования, нам нужно определить следующие вещи:
Исходя из вышеописанных моментов, мы можем принять решение о том, на сколько глубоко нам надо тестировать конкретное требование и какой вид документации лучше всего применить.
Например, если проект представляет собой сложную систему, с высокими рисками и нестабильной командой — то необходимо будет выбрать наиболее подробный вид документации, скажем тест-кейс. Из-за высоких рисков и сложности тесты необходимо будет проектировать на всех уровнях и максимально детально. Благодаря максимально проработанным тестам новым членам команды будет намного проще войти в проект нежели при использовании менее детальной документации.
Главный принцип для выбора документации — это окупаемость этой самой документации.
Я думаю логика понята. Чем сложнее, рискованней, дольше и стабильней наш проект, тем глубже и детальнее нужно прорабатывать тесты.
Для простого проекта, с невысокими рисками и продолжительность, с не совсем стабильными требованиями и стабильной командой можно использовать высокоуровневую тестовую документацию, например чек-листы (Checklists). В противном случае мы рискуем потратить большую часть времени на тест дизайн и поддержку документации, а не на выполнение тестов.
Иногда для проверки разных требований может применяться тестовая документация разных уровней.
Например, для сложного и рискового функционала — детальные тест кейсы, а для простого и нерискового — либо чек-лист, либо очень высокоуровневые тест-кейсы.
Зачем делать анализ тестирования?
Можно выделить 2 больших достоинства анализа тестирования:
После определения того, что мы будем делать, можно приступить к этапу создания тестов.
Проектирование тестов (тест дизайн, Test design)
Как было написано выше:
Проектирование тестов (тест дизайн, Test design) — это активность, которая определяет, как именно должно быть протестировано то, что было определено в рамках анализа тестирования.
То есть, это процесс перевода анализа тестирования в конкретные тесты (тест-кейсы, чек-листы, сценарии и тд)
Процесс тест дизайна включает в себя следующие активности:
Как правило, разработка тестов начинается с наиболее высокого уровня документации, постепенно снижаясь в уровне детализации тестов.
Из анализа тестирования у нас должно быть известно, что нам надо проверить, на каком уровне тестирования и какую документацию мы будем использовать.
Типовой пример с тест-кейсами:
В случае использования менее детализированной документации, можно пропустить шаг 3.
О чем ещё стоит подумать при проектировании тестов?
Для того чтобы эффективнее всего подобрать условия выполнения и входные данные для тестов нам помогут техники тестирования.
Техники тестирования (Test techniques, Test design techniques) — методы, используемые для создания и/или выбора входных данных и условий выполнения тестов.
По всем техникам тестирования мы пройдёмся как-нибудь в следующий раз. В рамках этой темы хотелось бы сказать, что для создания тест-кейсов подходят техники тестирования чёрного ящика (Black-box test techniques).
Так же, как и при анализе тестирования, проектирование тестов может привести к выявлению
аналогичных типов дефектов в требованиях (базисе тестирования). А выявление дефектов на ранних этапах проекта является важным потенциальным преимуществом для нашего продукта.
На сегодня у нас всё, в следующий раз разберём стадии реализации и выполнения тестов.
Тест дизайн что это
Тест-анализ = процесс поиска и рассмотрения информации, необходимой для тестирования. Обычно это люди со знаниями о системе и процессах, а также документация (требования, спецификации, описания архитектуры и интеграции и т.п).
Эта информация нужна для составления тест-кейсов.
Тестовое покрытие = покрытие тестами требований к продукту/системе, выраженное в численном либо процентном соотношении. Тестовое покрытие является одной из основных метрик качества продукта.
Иногда под тестовым покрытием имеют в виду покрытие критериев приёмки, покрытие кода, покрытие именно автотестами.
Тестовое покрытие говорит о добротности тестирования, о степени доверия к продукту, который мы делаем, о том где у нас есть «белые пятна» и выше риск проявления ошибки.
Процесс определения покрытия кратко картинкой:
Итак, вы прошли этап определения причастных сторон, ознакомились с документацией по Проекту, получили описание архитектуры Продукта/Системы, требования к ней, критерии приёмки.
Теперь надо определиться с объёмом тестирования и видами тестирования.
Матрица трассируемости требований (Requirement Traceability Matrix) = двумерная таблица, содержащая соответствие требований (user/business requirements, software requirements) и подготовленных тест-кейсов (test cases).
Основное её предназначение в отображении степени покрытия требований тест-кейсами.
В соответствии с лучшими практиками, Бизнес-Требования следует максимально декомпозировать и нумеровать в соответствии со следующим правилом: BR001, BR002 и т.д.
Для каждого Бизнес-Требования будет одно или несколько Функциональных Требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования также должны быть максимально декомпозированы.
Пример рабочего процесса, в котором присутствует создание Матрицы Трассировки:
Формат тест-кейса
Определение классов эквивалентности (Equivalence Partitioning)
и Анализ Граничных Значений (Boundary Value Analysis)
Попарное тестирование (Pairwise Testing)
Метод, основывающийся на тестировании комбинаций, с учётом того, чтобы каждое значение всех параметров хотя бы единожды сочеталось в проверках с другими значениями остальных параметров. Метод сильно уменьшает объём тестирования, но увеличивает вероятность пропуска дефекта.
Пример «оптимизации» оптимизации количества тестов этим методом:
Причина / Следствие (Cause/Effect)
Тестирование смены состояний (State Transition Testing)
Таблица решений (Decision Table Testing)
Способ компактного представления модели со сложной логикой. Устанавливает связь между условиями (входными параметрами) и результатом (действиями Системы). Определить/записать все условия. Просчитать возможное количество комбинаций условий. Заполнить комбинации. Записать действия. Убрать лишние комбинации.
Например:
Тестирование путей (Path Testing)
Однако, его же можно использовать для покрытия тестами логики тестируемой системы, если у нас имеются BPMN-диаграммы и UML activity-диаграммы, описывающие процессы, проходящие в ней.
Количество сценариев будет зависеть от количества логических узлов ветвлений. Если условия ветвлений зависят от значений каких-то данных, то скорее всего, для каждого тест-сценария необходимо, опираясь на диаграмму, определить набор входных данных.
Очень упрощённо:
Предугадывание ошибки (Error Guessing)
Это когда тест-аналитик/тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест-аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? «, и так далее. Это и есть предугадывание ошибки.
Исчерпывающее тестирование (Exhaustive Testing)
говориМ о тестировании
простым языком
Обзор техник тест-дизайна
Очень часто мне приходилось сталкиваться с тем, что начинающие тестировщики (да и я сам раньше) путают понятия. Например, исследовательское тестирование — это техника или вид? А функциональное тестирование? Давайте разбираться.
Понятно, что я сам не смогу ответить на этот вопрос, но этого и не нужно. Достаточно обратиться к стандартам и посмотреть, какую же классификацию техник они предлагают. Далеко ходить не стал, посмотрел в сторону ISTQB и вот что получилось.
В первую очередь выделяют три категории методов проектирования тестов:
Методы черного ящика основываются на анализе как требований и спецификаций, так и самого продукта.
Можно сказать, что в этом случае мы подходим к тестированию продукта, как к черному ящику. Мы не знаем, что внутри системы, не видим ее код и архитектуру. Чем-то мы похожи на обычных пользователей, которые видят лишь итог работы команды разработки. Мы тестируем ящик, но не знаем, что находится внутри.
Методы белого ящика являются абсолютной противоположностью методам черного ящика и основываются на анализе архитектуры приложения, внутренней структуры и кода системы.
С помощью этого метода мы заглядываем внутрь объекта тестирования и знаем, как он устроен. Особенностью этих методов является то, что для тестирования не обязательно запускать программу, достаточно взглянуть на исходный код.
Методы, основанные на опыте, используют опыт разработчиков, тестировщиков и пользователей для проектирования, реализации и выполнения тестов. Их часто совмещают с методами черного и белого ящиков.
Итак, если это категории методов, значит они должны включать в себя и сами методы тест-дизайна (проектирования тестов). Давайте посмотрим, какие техники предлагает нам ISTQB.
Методы черного ящика (Black-box Test Techniques)
Методы белого ящика
Методы, основанные на опыте (Experience-based Test Techniques)
Вот и все. Получается не так много, но познавательно. Думаю, это поможет начинающим тестировщикам немного больше понять тестирование и структуру техник тест-дизайна.
Попарное тестирование: суть техники, инструменты и примеры
Что такое попарное тестирование и почему оно является эффективной техникой тест-дизайна? Поговорим об этом ниже. Статья предназначена для начинающих специалистов по тестированию.
В этой статье пойдет речь о комбинаторной технике попарного тестирования (известной также как Pairwise testing или All-pairs testing).
Умное тестирование служит во благо экономии времени. Часто команда тестировщиков вынуждена работать в рамках жестких сроков 90% своего времени. По этой причине техники тест-дизайна должны быть эффективными, чтобы с их помощью можно было достичь максимально возможной степени покрытия тестами и вероятности обнаружения дефектов.
Что такое попарное тестирование?
Попарное тестирование — это техника тест-дизайна, которая обеспечивает полное тестовое покрытие.
ISTQB определяет попарное тестирование как технику тест-дизайна методом черного ящика, при которой тест-кейсы создаются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.
Результат работы приложения зависит от многих факторов, например, входных параметров, переменных состояний и конфигураций среды. Для определения возможных значений могут быть полезны такие техники, как анализ граничных значений и использование классов эквивалентности. Однако тестировать все возможные комбинации значений для всех факторов — непрактично. Поэтому, чтобы удовлетворить все факторы, генерируется подмножество комбинаций.
Техника попарного тестирования очень помогает при разработке тестов для приложений, включающих множество параметров. Тесты разрабатываются таким образом, что для каждой пары входных параметров существуют все возможные комбинации этих параметров. Тестовые наборы (тест-сьюты, Test suite) охватывают все комбинации. Поэтому техника хоть и не обеспечивает исчерпывающее тестирование, но все же является эффективной для поиска ошибок.
Давайте посмотрим, как применять технику попарного тестирования на примере.
Пример применения попарного тестирования
Приложение для заказа автомобиля:
С помощью приложения можно покупать и продавать машины. Приложение должно поддерживать оказание услуг в Дели и Мумбаи.
В приложении должны содержаться регистрационные номера, которые могут быть валидными и невалидным. Оно должно разрешать продажу следующих марок автомобилей: BMW, Audi и Mercedes.
Доступны два типа бронирования: бронирование через интернет и в офлайн-магазине.
Заказы доступны к размещению только в рабочие часы.
Шаг 1. Перечислим задействованные переменные.
Категория заказа
а. Купить
б. Продать
Местоположение
а. Дели
б. Мумбаи
Марка автомобиля
а. BMW
б. Audi
в. Mercedes
Регистрационные номера
а. Валидные (5000)
б. Невалидные
Тип заказа
а. Заказ через Интернет
б. Заказ в магазине
Время заказа
а. Рабочие часы
б. Нерабочие часы
Если тестировать все возможные допустимые комбинации: 2 X 2 X 3 X 5000 X 2 X 2 = получаем 240 тысяч комбинаций 🙁 Кроме того, недопустимых комбинаций вообще может быть бесконечное количество.
Шаг №2: Давайте упростим
Используем умную репрезентативную выборку.
Используем классы эквивалентности и граничные значения, даже если данные — непрерывные.
Сокращаем регистрационные номера до двух типов:
Валидный регистрационный номер
Невалидный регистрационный номер
Теперь посчитаем количество возможных комбинаций: = 2 X 2 X 3 X 2 X 2 X 2 = 96
Шаг 3. Упорядочивание задействованных переменных и значений.
Когда мы классифицируем задействованные переменные и значения, то получим что-то вроде этого:
Теперь отсортируем переменные так, чтобы переменные с наибольшим количеством значений шли первыми, а с наименьшим — последними.
Шаг 4. Расставляем переменные для создания набора тестов.
Давайте начнем заполнять таблицу столбец за столбцом. Изначально таблица выглядит примерно таким образом. Три значения в столбце «Марка авто» (переменная с наибольшим количеством значений) напишем дважды каждое (потому что следующая переменная, «Категория заказа», содержит два значения.
Столбец «Категория заказа» содержит два значения. И именно столько раз нам надо вставить значения первого столбца «Марка авто».
Для каждого набора значений в первом столбце мы помещаем оба значения второго столбца. Повторяем то же самое для третьего столбца.
Теперь у нас есть Покупка&Дели, но нет Покупка&Мумбаи. Есть Продажа&Мумбаи, но нет Продажа&Дели. Давайте поменяем значения из второго набора в третьем столбце.
Так уже выглядит получше.
Повторим шаги для столбцов 3 и 4.
Если сравнить столбцы 3 и 4, каждое значение из столбца 3 имеет пару с обоими значениями из столбца 4. Но если сравнить второй и четвертый столбец, у нас есть комбинации Покупка&Валидный и Продажа&Невалидный, но нет комбинаций Покупка&Невалидный и Продажа&Валидный. Следовательно, нам надо поменять местами последний набор значений в четвертом столбце.
С шестым столбцом (Время заказа) у нас проблемка: не хватает пар Покупка&Нерабочие часы и Продажа&Рабочие часы. Нам не удастся получить недостающие пары, поменяв значения местами, поскольку мы ранее уже поменяли местами все строки, и если мы снова начнём их менять, то есть риск пропустить другие возможные пары. Поэтому добавим еще два тестовых случая, которые содержат эти пары. Заполним пустые строки!
Теперь мы заполним пустые ячейки на свое усмотрение, потому что другие значения переменных являются произвольными (обозначим знаком тильды
Итого мы получили всего 8 тест-кейсов вместо 96.
Мы увидели, насколько эффективной может быть техника попарного тестирования. Она здорово повышает шансы найти баги, при этом сохранив время.
Однако эта техника имеет и некоторые ограничения. Она не сработает, если:
выбранные для тестирования значения некорректны;
мало внимания уделяется комбинациям, которые могут привести к ошибке с высокой долей вероятности;
взаимодействие между переменными недостаточно изучено.
Инструменты попарного тестирования:
Приведем примеры популярных инструментов, которые помогают эффективно автоматизировать процесс дизайна тест-кейсов путем создания компактного набора значений параметров в качестве желаемых тест-кейсов:
PICT – Попарное независимое комбинаторное тестирование от Microsoft Corp.
IBM FoCuS – Единое решение для функционального покрытия от IBM.
ACTS – Расширенная комбинаторная система тестирования от NIST, агентства правительства США.
VPTag – бесплатный инструмент попарного тестирования
Заключение:
Техника попарного тестирования помогает существенно уменьшить количество комбинаций проверок, достаточных для обеспечения необходимого уровня качества программного обеспечения. Это в самом деле умная техника тест-дизайна, которая гарантирует беспроигрышный результат как с точки зрения усилий и задействованных ресурсов, так и с точки зрения эффективности тестирования.
Об этой технике стоит помнить на этапе планирования тестирования. Независимо от того, генерируются ли тестовые случаи вручную или используется какой-либо вспомогательный инструмент, она становится необходимым компонентом тест-плана, потому что влияет на оценку тестирования.
Всех желающих приглашаем на бесплатное demo-занятие «Теория тестирования: виды тестирования». Чтобы быть хорошим специалистом, нужно понимать, какие виды тестирования бывают. На этом занятии мы:
— обсудим, по каким направлениям можно протестировать наш программный продукт;
— узнаем, что скрывается за белыми и черными ящиками;
— а также обсудим, чем отличаются стресс тесты от нагрузочных.