3 Тест-дизайн: Стратегии, техники и практические кейсы для тестировщиков

Тест-дизайн: Основы и техники

Введение в тест-дизайн

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

• Уточнение о видимости экрана и подготовка к обсуждению тематики тест-дизайна.

Определение тест-дизайна

• Тест-дизайн — это постоянный процесс для тестировщиков, который может выполняться неосознанно.

• Это один из первоначальных этапов тестирования ПО, где проектируются и создаются тестовые случаи (тест-кейсы).

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

• Основная цель — обеспечить покрытие функционала приложения с помощью написания соответствующих тестов.

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

Минимальная достаточность в тестах

• Критерий минимальной достаточности — важный аспект процесса тестирования; необходимо создать минимальное количество проверок для максимального покрытия пользовательских ожиданий.

• Количество тестов не всегда означает их качество; важно находить баланс между количеством и эффективностью.

Анализ требований и оценка рисков

• Анализ требований к продукту необходим для написания адекватных и правильных тестов.

Тестирование: Как находить ошибки, которые важны для пользователей

Проблемы с тестированием и восприятием ошибок

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

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

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

Классификация тестов

• Необходимо разделять тесты на приемочные и регрессионные. Понимание функционала продукта критично для правильной классификации тестов.

• Приемочные тесты (или смок-тесты) проверяют основные функции приложения. Важно помнить о различных уровнях тестирования и их назначении.

• Регрессионные тесты также имеют свои особенности и могут частично пересекаться с приемочными. Однако они не всегда являются расширенными.

Сейнити-тестирование

• Перед выкатыванием новой функциональности важно проводить сейнити-тестирование — глубокую проверку всех подфункций системы.

• Сейнити-тестирование помогает выявить проблемы до выхода функциональности в продакшн. После этого изменения будут редкими.

Процесс написания тест-дизайна

• При создании тест-дизайнов необходимо понимать задачи каждого конкретного теста и его место в процессе проверки функциональности.

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

Декомпозиция функционала

• Для адекватного написания тестов важно декомпозировать приложение на более мелкие части и понимать каждую из них.

• Декомпозиция позволяет лучше понять функционал приложения и его возможности при поиске информации о нем.

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

Поиск информации для создания качественных тестов

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

Тестирование и логическая взаимосвязь

Проблема прерывания и тестирования

• Обсуждение важности умения прерывать задачи в жизни и тестировании. Умение расставлять приоритеты влияет на качество тестирования.

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

Причинно-следственные связи

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

• Подчёркивается важность понимания логической взаимосвязи между ошибками и действиями пользователей или тестировщиков.

Ошибки пользователей

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

• Даже неправильные действия пользователя приводят к ошибкам, которые должны быть корректно обработаны системой.

Роль тестировщика

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

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

Методы тест-дизайна

Знание техник

• Обсуждение значимости знаний техник тест-дизайна для повышения квалификации специалистов в области QA.

Основные техники

• Перечисление основных техник: эквивалентные классы, граничные значения, exploratory testing, PR-WICE, состояния и переходы, таблицы решений и exhaustive tests.

Эквивалентные классы

• Определение эквивалентных классов как одной из самых распространённых техник. Она включает группы значений, которые ведут к одинаковым результатам при тестировании.

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

• Пример с формой определения инвалидности по возрасту иллюстрирует применение эквивалентных классов: разные возрастные группы обрабатываются по-разному.

Сокращение числа тестов

Тестирование программного обеспечения: Техники и подходы

Основные идеи тестирования

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

• Применение принципа сокращения количества проверок. Вместо проверки всех возможных значений, достаточно протестировать крайние значения и одно значение из середины диапазона.

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

Граничные значения и эквивалентные классы

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

• Если возникают сомнения по поводу различий между значениями (например, 15 и 9), это может указывать на необходимость проверки всех значений в случае наличия разных классов эквивалентности.

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

Проверка граничных значений

• Обсуждается техника тестирования граничных значений как важный аспект процесса тестирования. Упоминается пример с комиссией за билеты в зависимости от времени до вылета.

• Приводится пример с границами скидок в магазине. Если пользователь покупает на сумму ровно 500 гривен или 1000 гривен, важно проверить корректность применения скидок.

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

Вероятностный анализ границ

• Обсуждается вероятность попадания пользователей в граничные значения и как это влияет на выбор техник тестирования. Если вероятность низкая — можно опустить некоторые проверки.

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

Развитие техник тестирования

• Упоминается необходимость использования дополнительных техник для анализа поведения приложения на границах классов эквивалентности.

• Поясняется концепция "граничного значения" как точки изменения поведения приложения и ее влияние на результаты тестирования.

Что может произойти на границе?

Проблемы с границами и знаками

• Обсуждается возможность ошибки при установке знака "кровно", что может привести к неправильному определению диапазонов.

• Если знак не установлен, покупатель, который ожидал скидку, может остаться разочарованным из-за отсутствия скидки.

• Ошибка в установке знака может привести к тому, что клиент не получит ожидаемую скидку даже при покупке на большую сумму.

Важность верхнего и нижнего диапазона

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

• При тестировании значений необходимо учитывать логику работы с верхними и нижними границами.

Тестирование эквивалентных классов

Проверки и их необходимость

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

• Упоминается случай студента, который смог сократить количество проверок благодаря пониманию логики тестирования.

Значение граничных значений

• Говорится о важности осознания того, что некоторые проверки могут быть лишними в зависимости от контекста задачи.

Методы тестирования

Эксплоративное тестирование

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

• Этот подход полезен для стартапов или проектов с ограниченными временными рамками.

Преимущества и недостатки

• Эксплоративное тестирование позволяет использовать интуицию тестировщика для выявления проблем.

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

Передача знаний в команде

Как делиться опытом

• При обучении новых сотрудников важно объяснять свои методы и подходы к тестированию.

Как тестировать приложения без заранее написанных тестов?

Процесс тестирования без тест-кейсов

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

• Если у вас есть полное описание функционала, вы можете заранее написать тест-кейсы. Однако если функционал реализован неправильно или в неверной последовательности, эти кейсы могут оказаться неприменимыми.

Проблемы с формализацией и экскоритарное тестирование

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

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

Начало с экскоритарного подхода

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

• Для понимания работы функциональности через время необходимо зафиксировать ключевые проверки для будущих обновлений.

Понимание техники "Первать"

• Многие начинающие тестировщики считают технику "Первать" универсальной. На самом деле это ограниченная техника, которая подходит только для определенных случаев.

• Хотя "Первать" может сократить количество проверок, она не является панацеей для всех ситуаций.

Комбинации параметров в тестировании

• Рассматривается пример с тремя параметрами (операционная система, браузер и язык), каждый из которых может принимать два значения. Это приводит к 8 возможным комбинациям данных для тестирования.

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

Оптимизация количества проверок

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

Как Pay-wise помогает сократить количество проверок?

Основные идеи и концепции

• Обсуждение количества проверок: Приведены примеры с 5 параметрами и 5 значениями, что приводит к большому количеству возможных комбинаций. Упоминается, что это связано с комбинаторикой.

• Введение в Pay-wise: Утверждается, что использование инструмента Pay-wise позволяет значительно сократить количество необходимых проверок за счет геометрической прогрессии.

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

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

• Экономия на проверках: Уточняется, что методика Pay-wise позволяет охватить множество вероятностей при меньшем количестве проверок, особенно для однотипных тестов в разных средах.

• Ограничения применения: Если пользовательский сценарий отличается (например, смена языка), применение Pay-wise может быть ограничено или неэффективно.

Состояния и события в приложении

• Переходы состояний: Объясняется концепция состояний приложения и событий (внешних и внутренних), которые могут влиять на поведение системы.

• Внешние vs внутренние события: Приводится пример внешнего события (нажатие кнопки "оплатить") по сравнению с внутренним событием (автоматическое изменение состояния корзины).

Примеры переходов состояний

• Состояние выбора билетов: Описывается процесс выбора мест в зале и перехода к состоянию "оплата".

• Возможные переходы после выбора: Рассматриваются три типа переходов — оплата, отмена пользователем и истечение времени ожидания оплаты.

Анализ статусов изменений

• Внутренние изменения состояния: Обсуждаются последствия различных действий пользователя на состояние билетов в системе (например, возврат билетов в продажу).

Код продверсения и его изменения

Изменения в билетах после оплаты

• После оплаты билетов, которые изначально были в статусе Mate, изменяются параметры, такие как Paytime и PaidEd, где фиксируется время.

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

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

• В процессе добавляется новый признак "Paid", а также "Тикат Tru" и "Youth". Эти признаки помогают отслеживать состояние билета.

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

Проблемы с синхронизацией данных

Задержки при использовании билетов

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

• Люди могли пройти с уже использованным билетом из-за запоздания в синхронизации данных между устройствами.

Дублирование сканирования

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

• Разница во времени использования билета могла составлять доли секунды из-за задержек в синхронизации.

Техника тестирования переходов состояний

Моделирование состояний системы

• Для понимания системы важно нарисовать диаграмму состояний с переходами между ними. Это помогает выявить все возможные состояния и их взаимодействия.

• На основе этой диаграммы можно создавать тест-кейсы для каждого перехода состояния системы.

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

• Использование данной техники позволяет покрыть сложный функционал тестами и избежать пропусков важных переходов.

• Автор делится опытом применения этой техники на проектах с большим количеством переходов между состояниями.

Обсуждение результатов работы

Реакция команды на результаты

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

Как работает система переходов?

Обсуждение системы и ее визуализации

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

• Приводится пример с билетами на концерт: билеты нельзя отменить, если только концерт не отменен. Это подчеркивает важность понимания правил в системе.

• Участник выражает удивление по поводу строгих правил возврата билетов и их влияния на пользователей.

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

Машина состояний в программировании

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

• Вопрос о том, использовалась ли машина состояний до начала разработки. Участник делится опытом использования таких описаний для тестирования.

Тестирование и описание требований

• Описывается двойная природа машины состояний: она может служить как для тест-дизайна, так и для постановки задач разработчикам.

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

Интеграция машин состояний в процесс разработки

• Обсуждается возможность интеграции машин состояний в процесс разработки и тестирования. Это позволяет избежать недопонимания между командами.

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

Проверка покрытия тестами

• Говорится о необходимости проверки всех переходов с помощью тест-кейсов. Это помогает убедиться, что ничего не упущено при тестировании системы.

• Приводится пример создания набора из шести тест-кейсов для проверки всех возможных переходов системы.

Заключение о требованиях к системам

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

Техническая документация и юзерстори

Введение в юзерстори

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

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

Процесс создания юзерстори

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

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

Сертификация и обучение

• Объяснение различий между курсами с сертификацией и без. Сертификация требует дополнительных затрат и усилий.

• Личный опыт автора в проведении тренингов по скраму в банке; использование материалов из курса тестирования.

Методы принятия решений

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

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

• Описание техники States Interaction как способа обсуждения состояний системы с заказчиком.

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

• Определение таблицы принятия решений как метода фиксации входных комбинаций и соответствующих поведений системы.

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

Создание тест-кейсов

• Обсуждение возможности создания кумулятивного тест-кейса на основе простого интерфейса.

Обсуждение тестирования и оптимизации таблиц

Процесс создания таблицы

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

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

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

Оптимизация и исключение вариантов

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

• Создание "грубого" материала (таблицы), который затем будет обработан и оптимизирован для упрощения анализа.

Проверка и выявление ошибок

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

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

Техника РРГСН: Предугадание ошибок

Необходимые навыки для использования РРГСН

• Обсуждаются предусловия для применения техники РРГСН: необходимо умение декомпозировать систему и внимание к деталям.

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

Применение РРГСН в практике

• Техника РРГСН позволяет опытным тестировщикам предугадывать места возникновения ошибок благодаря их пониманию продукта.

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

Эффективная коммуникация с руководством

Как представить свою работу начальству

• Важно правильно формулировать свои действия при общении с руководством; использование термина РРГСН может звучать слабо без объяснения его сути.

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

Заключительные мысли о работе в команде

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

Экзостерное тестирование: Понимание и Применение

Основные концепции экзостерного тестирования

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

• Тестирование ограничивается тем, насколько хорошо тестировщик может охватить все обстоятельства. Полнота тестирования зависит от опыта и знаний тестировщика.

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

Критерии успешного экзостерного тестирования

• Важно определить критерии, по которым можно считать экзостерное тестирование завершённым. Это включает в себя понимание объективных сценариев, которые были протестированы.

• Необходимо оценивать вероятность возникновения ошибок и ответственность за них. Экзостерное тестирование отличается от других техник тем, что оно не стремится экономить время на проверках.

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

• Пример с PR-WICE показывает, что эта техника позволяет выявить 90% ошибок при сочетании параметров. Однако в критических системах (например, кардиостимуляторах) нельзя полагаться только на эту технику.

• При разработке кардиостимуляторов важно учитывать жизнь человека; сокращение времени на проверки может привести к серьёзным последствиям.

Контекст и важность проверки

• Важно помнить о контексте при применении экзостерного тестирования. Если речь идёт о здоровье людей или больших финансовых потерях, необходимо проводить более тщательные проверки.

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

Заключительные мысли и дальнейшие шаги

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

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

Обсуждение курса и его целевой аудитории

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

• Упоминается, что курс должен завершиться после 6-8 занятий, после чего будет возможность задать вопросы и обсудить кейсы.

Проблемы в тестировании программного обеспечения

• Спикер отмечает, что обсуждаемые темы не зависят от контекста конкретного проекта, но важно понимать их применение.

• States Interntation может быть применимо ко многим аспектам разработки и тестирования программного обеспечения.

Трудности с документацией

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

• Упоминается необходимость проведения тестов на существующих продуктах для выявления проблем с новыми функциями.

Подход к тестированию

• Спикер предлагает подход к тестированию через написание тест-кейсов на основе существующего функционала.

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

Роль команды в процессе разработки

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

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

Заключение о будущем обучении

• Спикер призывает разработчиков участвовать в следующих занятиях по Scrum и User Story для улучшения процессов работы над проектами.

Как правильно писать User Story?

Введение в User Story

• Обсуждение важности написания User Story с точки зрения пользователя, а не разработчика. Упоминается, что разработчики могут не всегда понимать, как это должно быть использовано.

Процесс разработки и методологии

• Спикер предлагает провести встречу для обсуждения процесса разработки в рамках Scrum и делится своими сертификациями по Scrum. Он готов рассказать много о различных методологиях, таких как Kanban.

Вопросы и взаимодействие

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

Мотивация участников

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

Проблемы восприятия информации

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

Заключение встречи