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

Что проверяем: функции и всё остальное

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

Функциональное тестирование отвечает на вопрос «что делает приложение»: можно ли войти, добавить товар в корзину, оплатить, получить письмо. Этим тестировщики занимаются больше всего.

Нефункциональное тестирование отвечает на вопрос «как оно это делает»:

Вид	Что проверяет	Пример
Производительность и нагрузка	Скорость и поведение под нагрузкой	Выдержит ли сайт 10 000 покупателей в распродажу
Безопасность	Защиту данных и доступа	Можно ли увидеть чужой заказ, подменив номер в адресе
Удобство	Понятно ли пользоваться	Найдёт ли человек кнопку оплаты без подсказок
Совместимость	Работу в разных условиях	Работает ли сайт в Safari и на старом телефоне
Доступность	Работу для людей с ограничениями	Можно ли пользоваться сайтом без мыши, с экранным диктором

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

Как глубоко проверяем

• Смоук-тестирование (smoke) — быстрая проверка главного: приложение открывается, работают вход и основные сценарии. Название пришло из электроники: включили устройство — не пошёл ли дым. Если смоук не пройден, сборку сразу возвращают разработчикам.
• Регрессионное тестирование — проверка того, что изменения не сломали то, что раньше работало. Исправили корзину — проверяем заодно оплату, вход и каталог. Регресс проводят перед каждым выпуском, и именно его чаще всего автоматизируют.
• Повторное тестирование (ретест) — проверка конкретного бага после исправления: тот самый шаг «Проверка» из жизненного цикла бага.

На каком уровне проверяем

Уровни идут снизу вверх: от проверки маленьких кусочков кода до приёмки всего продукта.

1. Приёмочноезаказчик или пользователи: то ли сделали, что хотели
2. Системноевсё приложение, как его видит пользователь. Здесь работает большинство тестировщиков
3. Интеграционноекак части работают вместе, например сайт и платёжный сервис
4. Модульноеотдельные кусочки кода, проверки пишут разработчики

Ручное и автоматизированное

Ручное тестирование гибкое: человек замечает странности, о которых никто не подумал. Автоматизированное — быстрое и неутомимое: однажды написанный тест можно запускать хоть каждый час.

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

Что такое API и зачем его тестировать

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

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

Мобильные приложения: что добавляется

У мобильного тестирования свои особенности:

• прерывания — входящий звонок, уведомление или сворачивание приложения посреди оплаты;
• плохая сеть — переход с Wi-Fi на мобильный интернет, метро, режим полёта;
• поворот экрана и разные размеры дисплеев;
• разные системы — Android и iOS, старые и новые версии;
• разрешения — что будет, если не дать доступ к камере или геолокации.