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

TDD - Test Driven Development

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

Есть два уровня TDD:

• Acceptance TDD (ATDD): вы пишете один приемочный тест. Этот тест удовлетворяет требованиям спецификации или удовлетворяет поведению системы. После этого пишете достаточно производственного / функционального кода, чтобы выполнить этот приемочный тест. Приемочный тест фокусируется на общем поведении системы. ATDD также известен как BDD - Behavior Driven Development;
• Developer TDD: вы пишете один тест разработчика, то есть модульный тест, а затем просто достаточно производственного кода для выполнения этого теста. Модульное тестирование фокусируется на каждой небольшой функциональности системы. Это называется просто TDD. Основная цель ATDD и TDD - определить подробные, выполнимые требования для вашего решения точно в срок (JIT). JIT означает принятие во внимание только тех требований, которые необходимы в системе, что повышает эффективность.

BDD - Behaviour Driven Development

Это разработка, основанная на описании поведения. Определенный человек(или люди) пишет описания вида "я как пользователь хочу когда нажали кнопку пуск тогда показывалось меню как на картинке" (там есть специально выделенные ключевые слова). Программисты давно написали специальные тулы, которые подобные описания переводят в тесты (иногда совсем прозрачно для программиста). А дальше классическая разработка с тестами (TDD);

TDD - Type Driven Development

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

DDD - Domain Driven Design

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

FDD - Features Driven Development

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

MDD - Model Driven Development

Разработка, управляемая моделями - это стиль разработки программного обеспечения, когда модели становятся основными артефактами разработки, из которых генерируется код и другие артефакты;

PDD - Panic Driven Development

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

ADD - API Driven Development

Разработка на основе API - это практика сначала проектирования и создания API, а затем создания на их основе остальной части приложения;

BDT - Behavior Driven Testing

В тестировании на основе поведения ваши тесты основаны на user stories, которые описывают некоторые конкретные ожидаемые действия приложения. Вместо проверки деталей реализации вы фактически проверяете то, что важно больше всего: правильно ли приложение выполняет user stories. Еще одним преимуществом является понятность тестов для менеджеров, аналитиков и т.п.;

MDT - Model Driven Testing

Тестирование на основе моделей - это метод тестирования черного ящика, при котором поведение тестируемого программного обеспечения во время выполнения проверяется на основе прогнозов, сделанных моделями. Модель - это описание поведения системы. Поведение может быть описано в виде наглядной схемы, Data Flow, Control Flow, Dependency Graphs, Decision Tables, State transition machines или mind map. Простой аналогией модели в тестировании является электрическая схема при разработке электроприбора. Этот подход к тестированию требуется, когда высока цена ошибки в большом продукте и нужно как можно раньше попытаться ее предотвратить;

DDT - Data Driven Testing (table-driven testing or parameterized testing)

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

VDT - Value Driven Testing

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

Подход к тестированию (Test Approach)

Подход к тестированию (test approach): Реализация стратегии тестирования для определенного проекта. Обычно включает в себя заключения, сделанные на основе цели (тестирования) проекта и анализе рисков, стартовые точки процесса тестирования, применяемые методики разработки тестов, критерии выхода, типы тестирования, которые должны быть произведены. (ISTQB)

Оценка риска (risk assessment): Процесс идентификации и последующего анализа определенного риска проекта или продукта с целью определить его уровень. Обычно состоит из назначения рейтинга вероятности и влияния. (ISTQB)

Цель тестирования (test target): Набор критериев выхода. (ISTQB)

Подход к тестированию - это реализация стратегии тестирования для конкретного проекта.

Подход к тестированию определяется и уточняется в test plans and test designs. Подход к тестированию обычно включает решения, принимаемые на основе цели (тестового) проекта и оценки рисков (risk assessment). Подход к тестированию является отправной точкой для планирования процесса тестирования, для выбора применяемых методов проектирования тестов и типов тестов, а также для определения критериев начала и окончания тестирования. Выбранный подход зависит от контекста и может учитывать риски, опасности и безопасность, доступные ресурсы и навыки, технологии, характер системы (например, custom built vs. commercially available off-the-shelf (COTS)), цели тестирования (test objectives) и правила.

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

• Упреждающий (Proactive) - подход, при котором test design process запускается как можно раньше, чтобы найти и исправить дефекты до создания сборки (build);
• Реактивный (Reactive) - подход, при котором тестирование не начинается до завершения проектирования и разработки.

Различные подходы к тестированию:

• Аналитические подходы (Analytical approaches), такие как risk-based testing, когда тестирование направлено на области наибольшего риска;
• Подходы на основе моделей (Model-based approaches), такие как стохастическое тестирование с использованием статистической информации о частоте отказов (например, модели роста надежности) или использовании (например, рабочие профили);
• Методические подходы (Methodical approaches), такие как основанные на отказах (failure-based) (включая error guessing and fault attacks), основанные на опыте, на основе чек-листов и на основе характеристик качества (experience-based, checklist-based, and quality characteristic-based);
• Подходы, соответствующие процессам или стандартам (Process- or standard-compliant approaches), например, указанные в отраслевых стандартах или различных гибких методологиях;
• Динамические и эвристические подходы (Dynamic and heuristic approaches), такие как exploratory testing, при котором тестирование более реагирующее (reactive) на события, чем при запланированном заранее (pre-planned), и где выполнение и оценка (execution and evaluation) являются параллельными задачами;
• Консультативные подходы (Consultative approaches) - подходы, при которых test coverage определяется в первую очередь советами и руководством экспертов в области технологий и / или бизнеса, не входящих в группу тестирования;
• Подходы против регрессии (Regression-averse approaches) - подходы, которые включают повторное использование существующего тестового материала, обширную автоматизацию функциональных регрессионных тестов и стандартные наборы тестов.

Можно комбинировать разные подходы, например, динамический подход, основанный на оценке риска.