Виды тестирования: что проверяют и кто

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

Место проверки в жизненном цикле разработки описано в статье 01-06. Здесь смотрим на сами проверки.

Кейс: «проверьте всё» перед релизом

В «Узелке» готовится релиз отмены заказа с причиной. Владелец просит тестировщика: «Проверь всё». Тестировщик уточняет: что считать «всем»? Правило отмены в коде? Работу кнопки с сервером? Что оформление заказа не пострадало? Что магазин выдержит распродажу? Это разные вопросы, и на каждый отвечает своя проверка. (Состав релиза условный: мы взяли его для иллюстрации.)

Если заранее назвать проверки и тех, кто их проводит, «всё» превращается в короткий список, по которому видно, что проверено, а что нет.

Уровень и вид: два разных вопроса

Обычно различают уровни и виды тестирования.

Уровень тестирования - это группа проверок, которые организуют и ведут вместе, привязанная к этапу разработки: от отдельных компонентов до всей системы. Уровень отвечает на вопрос «в каком масштабе проверяем».

Вид тестирования - это группа проверок, связанная с определённым качеством системы: что она делает, как быстро работает, выдерживает ли нагрузку. Вид отвечает на вопрос «что именно проверяем». Один и тот же вид может встречаться на разных уровнях.

Четыре уровня

Уровни обычно описывают так.

• Модульное (компонентное) тестирование проверяет самые мелкие части программы: функции и методы. Его обычно пишут сами разработчики рядом с кодом.
• Интеграционное тестирование проверяет, что объединённые части одной системы обмениваются данными без сбоев на стыках.
• Системное тестирование проверяет, что система целиком соответствует заданным требованиям.
• Приёмочное тестирование подтверждает, что система отвечает потребностям бизнеса и готова к запуску. Это проверка требований с точки зрения пользователя и заказчика.

Модульное и системное тестирование мы здесь не разбираем подробно. Нам важнее приёмочное и интеграционное: критерии приёмки описаны в статье 02-09, а от стыков между системами зависит проектирование интеграций.

Виды проверок

Виды дополняют уровни. Для работы с требованиями чаще всего встречаются три.

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

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

Кто проводит проверки

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

Наше участие в этих проверках сводится к понятным вещам: мы формулируем критерии приёмки, отвечаем на вопросы о том, что имелось в виду в требовании, и сверяем, что проверки покрывают требования (как именно, разберём в статье 02-25).

Один релиз по порядку

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

Где это встречается в работе

• Планирование релиза: какие проверки входят в состав работ.
• Обсуждение сроков с командой: тестирование тоже входит в оценку (статья 02-23).
• Приёмка релиза вместе с владельцем продукта (статья 02-09).
• Разбор дефекта: на каком уровне его должны были поймать.
• Подготовка тест-кейсов по требованиям (статья 02-25).

Итог

Уровень отвечает на вопрос «в каком масштабе проверяем», вид отвечает на вопрос «что именно проверяем». Четыре уровня идут от модульного к приёмочному, а виды вроде функционального, регрессионного и нагрузочного пересекаются с ними. Исполнителя проверки лучше назвать заранее: однозначно можно назвать только разработчиков для модульных тестов и бизнес для приёмки.

Что дальше

Дальше разберём, как из требований выводить тест-кейсы и как проходит приёмка (статья 02-25), а затем соберём чек-лист постановки задачи разработке (статья 02-26).