В предыдущей статье «Тестирование в массы» мы много говорили о том, что тестирование — неотъемлемая часть любого хорошего проекта и качественного решения. А как насчет качества самого тестирования? Рассказываем с кейсами из системы Directum.

Тестирование так или иначе всегда есть в вашем проекте. Результат самого тестирования и качество программного продукта зависят от тест-дизайна. Знаете ли вы, что такое тест-дизайн? Если да, то поздравляем — вы входите в число экспертов, которые значительно облегчают себе работу и точно знают, как  повысить её эффективность.

Уже сорок лет минуло с тех пор, как можно использовать и совершенствовать тест-дизайн. Отец тестирования программ и автор книги The Art of Software Testing Гленфорд Майерс ещё в 1979-м описал техники и подходы, которые стали основой для современных методов проектирования тестов. Это база, которая сохраняет свою актуальность и сегодня. 

Так что же такое тест-дизайн

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

Цели тест-дизайна

• обнаружение наиболее серьезных ошибок;
• минимизация количества тест-кейсов;
• минимизация времени на тестирование.

Этапы работы над тест-дизайном

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

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

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

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

Определение необходимого количества тестов – один из ключевых вопросов в тестировании программного обеспечения. Ответ на этот вопрос мы получаем как раз на этапе применения техник тест-дизайна.

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

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

Техники черного ящика опираются на анализ внешнего поведения объекта тестирования, без учета его внутренней структуры. К наиболее распространенным техникам черного ящика относятся:

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

Техники белого ящика опираются на анализ внутренней структуры объекта тестирования и процесса обработки данных.

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

В этой статье мы рассмотрим техники черного ящика.

Техника «Эквивалентное разбиение»

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

Существует два типа классов эквивалентности:

• правильные — соответствуют корректному поведению системы;
• неправильные — соответствуют ошибкам или некорректному поведению системы.

Порядок выполнения техники

1. Определение классов эквивалентности.
2. Выбор представителей.
3. Создание и выполнение тест-кейсов.

Пример техники эквивалентного разбиения

Рекомендации по определению классов эквивалентности

Если входное условие указывает диапазон значений, то определяются 1 допустимый класс эквивалентности и 2 недопустимых.

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

Если входное условие содержит выражение долженствования, то определяются 1 допустимый класс и 1 недопустимый класс ввода.

Техника «Анализ граничных значений»

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

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

Порядок выполнения техники

1. Определение границ.
2. Выделение значений, находящихся на границах: с минимальным отклонением, а также само граничное значение (при необходимости можно выделять еще и значения, являющиеся серединным).
3. Использование данных в проектировании тест-кейсов.

Примеры техники анализа граничных значений

 

Техника «Таблица принятия решений»

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

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

Порядок выполнения техники

1. Определение условий.
2. Определение действий.
3. Построение таблицы.
4. Создание и выполнение тест-кейсов.

Примеры техники «Таблица принятие решений»

 

Техника «Таблица переходов»

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

Строки таблицы представляют собой состояния, а столбцы - события (вместе с контрольными условиями).

Пример техники

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

Как пример можно привести обычный документ системы:

• первое состояние – документ ещё не создан,
• второе состояние – документ в разработке (Инициализация),
• третье состояние – утвержденный документ (Действующий),
• четвёртое – Устаревший (Аннулированный).

Между состояниями «Действующий» и «Устаревший» два действия. Поэтому необходимо искать все действия, которые влияют на изменение состояний.

 

Техника «Попарное тестирование»

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

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

Преимущества и недостатки техники попарного тестирования

 

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

1. Эффективное использование ресурсов. Парное тестирование помогает достичь высокого уровня тестового покрытия при минимальном количестве тест-кейсов. Это позволяет сэкономить ресурсы, ведь для проведения тестирования требуется меньше времени и усилий.

2. Сокращение времени до выхода на рынок. За счёт быстрого исправления дефектов попарное тестирование помогает сократить время до выпуска ИТ-продукта на рынок. Это особенно важно в условиях быстро меняющегося рынка.

3. Снижение рисков. Попарное тестирование помогает снизить риски, связанные с пропуском дефектов в важной функциональности ИТ-продукта, что может привести к финансовым потерям или ухудшению репутации компании.

4. Повышение качества продукта. Благодаря широкому охвату возможных взаимодействий между параметрами, попарное тестирование помогает выявить дефекты в ИТ-продукте ещё на ранних стадиях разработки. Это способствует повышению качества и надёжности ПО.

Недостатки попарного тестирования

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

2. Сложность выбора параметров. Выбор правильных параметров может быть сложной задачей. Неправильный выбор в некоторых случаях приводит к упущению ошибок.

 

Пример техники «Попарное тестирование»

Описание ситуации

Отправка задачи. Разработка задачи и её свойств.

 

У нас имеется два свойства – Тип и Старт. Свойство Тип имеет два варианта значений – задание и уведомление. Старт задачи может осуществляться одновременно или друг за другом. И таким образом составляем таблицу с комбинацией значений данных свойств.

 

Техника «Прогнозирование ошибок»

Это способ предотвращения ошибок, дефектов, основанный на знаниях тестировщика, включающих:

• историю работы системы в прошлом;
• наиболее вероятные типы дефектов, допускаемых при разработке;
• типы дефектов, которые были обнаружены в схожих приложениях.

Пример техники «Прогнозирование ошибок»

Описание ситуации

 

Рассмотрим в качестве примера карточку записи справочника Сотрудники и определим вопросы, которые необходимо выделить в данном случае:

1. Как работают другие справочники системы схожие со справочником Сотрудники?
2. Какие самые частые ошибки возникают в работе данных справочников?
3. Как справочник работал в прошлом?

Техника предсказывания ошибок будет эффективна, если:

• у тестировщика есть хороший опыт работы с такими же/подобными приложениями;
• имеется достаточно данных о поведении и ошибках приложения в прошлом;
• требования неадекватны, и формальные методы трудно применить;
• приложение или функциональность критически важны для бизнеса и существует веская причина приложить больше усилий для тестирования, применяя технику угадывания ошибок в дополнение к формальным методам.

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

 

Техника «Причинно-следственный анализ»

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

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

Пример техники «Причинно-следственный анализ»

Описание ситуации

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

Подобным образом также осуществляются фиксации в документации. Как пример всем нам знакомые тест-кейсы.

 

Причина:

1. Ввод входных данных в систему.
2. Нажатие кнопки Вход.

Следствие: авторизация прошла успешно.

 

* * *

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

Статью для вас подготовил аналитик-консультант Акелона

Борис Бурдалев