Одна проверка — много названий: на каком уровне, что проверяет, как придумана
Видов тестирования десятки, и они не исключают друг друга: это разные признаки одной проверки, как у товара есть цвет, размер и цена. Возьмём проверку «в интернет-магазине оформить заказ с купоном на скидку и убедиться, что сумма уменьшилась»:
| Признак | Вопрос | Ответ для этой проверки |
|---|---|---|
| Уровень | Какую часть программы проверяем? | Системный: всё приложение целиком |
| Цель | Что именно проверяем? | Функциональное: правильность расчёта |
| Знание кода | Смотрим ли внутрь? | Чёрный ящик: только интерфейс |
| Данные | Корректный ли ввод? | Позитивная: действующий купон |
| Повод | Зачем проверяем сейчас? | Например, регресс: купоны не меняли, но меняли корзину |
| Способ | Руками или программой? | Ручная |
Когда в тест-плане пишут «системное функциональное регрессионное тестирование», это не три разных работы, а одна, описанная по трём признакам.
Уровень отвечает на вопрос «насколько большой кусок программы проверяем за раз». Чем ниже уровень, тем раньше и дешевле находится дефект и тем точнее видно, где он.
| Уровень | Что проверяют | Кто обычно | Пример: интернет-магазин |
|---|---|---|---|
| Модульное (unit) | Отдельную функцию или класс в отрыве от остального | Разработчик, автотестами | Функция расчёта скидки возвращает 450 для суммы 5000 и купона 10% |
| Интеграционное | Взаимодействие частей: модулей, сервисов, базы, внешних систем | Разработчик или тестировщик | Сервис заказов правильно передаёт сумму в платёжный шлюз |
| Системное | Программу целиком, как её видит пользователь, на стенде, похожем на рабочий | Тестировщик | Покупатель находит товар, кладёт в корзину, оплачивает, получает письмо |
| Приёмочное | Готова ли программа к использованию: решает ли задачу заказчика | Заказчик, пользователи, иногда тестировщик по их сценариям | Менеджер магазина проводит день работы на новой версии и подписывает акт |
Ручной тестировщик работает в основном на системном уровне и участвует в интеграционном и приёмочном. Модульные тесты пишут программисты — этому посвящён курс автоматизации. Но знать о них нужно: если модульный тест функции расчёта скидки есть и проходит, на системном уровне достаточно пары проверок скидки, а не двадцати.
Функциональное тестирование проверяет, что делает программа: считает, сохраняет, находит, запрещает. Источник ожидаемого результата — функциональные требования: «заказ на сумму от 3000 ₽ доставляется бесплатно».
Нефункциональное проверяет, как программа это делает. Это характеристики качества из раздела 01, кроме функциональной пригодности:
| Вид | Вопрос | Пример проверки |
|---|---|---|
| Производительности | Как быстро отвечает при обычной нагрузке? | Каталог из 2000 товаров открывается быстрее 2 секунд |
| Нагрузочное | Выдержит ли ожидаемое число пользователей? | 500 покупателей одновременно оформляют заказы в «чёрную пятницу» |
| Удобства использования | Понятно ли без инструкции? | Новый покупатель находит, где ввести купон, без подсказки |
| Совместимости | Работает ли в нужном окружении? | Оформление заказа в Chrome, Firefox, Яндекс Браузере и на телефоне |
| Доступности | Может ли пользоваться человек с нарушениями зрения или моторики? | Форма заказа заполняется только с клавиатуры, у полей есть подписи |
| Безопасности | Защищены ли данные и доступ? | Покупатель не видит чужие заказы, подставив другой номер в адрес |
| Надёжности | Что будет при сбое? | Связь оборвалась на оплате — деньги не списались дважды |
Нагрузочное тестирование и полноценный анализ защищённости требуют отдельных инструментов и знаний — в этом курсе о них только понятия. Удобство, совместимость, доступность и простые проверки доступа к чужим данным ручной тестировщик делает сам: этому посвящены разделы 08 и 09.
Признак — что тестировщик знает о внутреннем устройстве программы.
В этом курсе вы начнёте с чёрного ящика, а с раздела 08 перейдёте к серому: инструменты разработчика в браузере, запросы к API и база данных покажут то, что не видно в интерфейсе.
Динамическое тестирование — программу запускают и смотрят, как она работает. Статическое — проверяют без запуска: читают требования, макеты, тест-кейсы, код. Найти в требованиях противоречие «доставка бесплатна от 3000 ₽» и «от 3500 ₽» — это статическое тестирование, и оно самое дешёвое: программы ещё нет, исправить — поменять слово.
К статическому относятся и рецензирование (взаимная проверка тест-кейсов в разделе 04), и автоматический анализ кода, который делают программы-анализаторы.
Эти виды различаются поводом: зачем мы проверяем именно сейчас.
| Вид | Повод | Объём | Пример |
|---|---|---|---|
| Дымовое (smoke) | Пришла новая сборка: можно ли её вообще тестировать? | 5–15 проверок главного, 10–20 минут | Сайт открывается, вход работает, товар кладётся в корзину, заказ оформляется |
| Повторное (re-test, подтверждающее) | Разработчик исправил дефект | Шаги баг-репорта | Купон «ОСЕНЬ10» снова уменьшает сумму — дефект закрыт |
| Регрессионное | Код изменили: не сломалось ли то, что работало? | От десятков до сотен проверок | После исправления купонов проверяют корзину, оплату, бонусы, письма |
Название «дымовое» пришло от электронщиков: включили плату — если пошёл дым, дальше проверять незачем. Если smoke не прошёл, сборку возвращают разработчикам и не тратят день на подробные проверки.
Повторное и регрессионное часто путают. Повторное отвечает «исправлено ли то, что чинили?», регрессионное — «не сломали ли починкой что-то рядом?». Исправление купонов могло задеть расчёт бонусов, который использует ту же функцию, — повторная проверка этого не заметит, регрессионная должна. В разделе 11 вы проведёте и то и другое на новой версии «Задачника».
Позитивная проверка — корректные данные и обычные действия: программа должна выполнить операцию. Негативная — некорректные данные или запрещённые действия: программа должна отказать понятно и безопасно, не упасть и не испортить данные.
Пример — поле «Количество» в корзине, допустимо от 1 до 99:
| Тип | Ввод | Ожидаемый результат |
|---|---|---|
| Позитивная | 1, 5, 99 | Количество принято, сумма пересчитана |
| Негативная | 0, 100, −1 | Сообщение «от 1 до 99», количество не изменилось |
| Негативная | «пять», 2.5, пусто | Сообщение о формате, страница не сломалась |
| Негативная | Купить больше, чем на складе | Сообщение «в наличии 3 шт.» |
Начинают с позитивных: если основная операция не работает, негативные проверять рано. Но большинство дефектов прячется в негативных — разработчик лучше всего продумывает тот путь, который сам проверял.
По сценариям (scripted) — проверки написаны заранее: тест-кейсы с шагами и ожидаемым результатом, их проходят и отмечают итог. Плюсы — повторяемость, видно покрытие, можно поручить новичку. Минусы — пишутся долго и со временем находят всё меньше (парадокс пестицида).
Исследовательское (exploratory) — проверки придумываются по ходу, как в первом проходе раздела 01. Плюсы — быстро стартует, находит неожиданное. Минусы — зависит от опыта, трудно сказать, что именно проверено, если не вести записи.
На практике их сочетают. Новую функцию сначала исследуют, по итогам пишут чек-лист и тест-кейсы на главное, а перед выпуском проходят тест-кейсы и добавляют короткое исследование того, что менялось.
Есть и вовсе неформальное свободное (ad hoc) тестирование — без цели, времени и записей. Оно иногда что-то находит, но результат нельзя ни повторить, ни учесть в отчёте, поэтому в этом курсе каждый проход имеет цель, время и записи.
Автотест — программа, которая сама выполняет шаги и сверяет результат. Он выгоден, когда проверку нужно повторять часто и одинаково: регресс перед каждым выпуском, сотни комбинаций данных, API. Ручная проверка выгодна, когда функция ещё меняется, проверка нужна один-два раза или требует человеческой оценки: удобно ли, понятно ли, красиво ли.
Автотесты не заменяют ручное тестирование: автоматизируют то, что уже проверено руками и записано тест-кейсом. Поэтому курс автоматизации идёт после этого.