Какие знаешь классификации видов тестирования?

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

Как QA с 10+ лет опыта, я использую множество классификаций для структурирования тестовой стратегии. Каждая классификация отражает разные аспекты тестирования.

Классификация по уровню тестирования

Unit-тестирование

• Объект: Отдельные функции, методы, модули
• Кто пишет: Разработчики
• Инструменты: Jest, pytest, JUnit, Mocha
• Скорость: Очень быстро (миллисекунды)
• Охват: 80-90% кода в идеале
• Примеры: Тест функции расчёта скидки, валидации email

Интеграционное тестирование

• Объект: Взаимодействие между модулями, компонентами
• Кто пишет: QA + разработчики
• Инструменты: TestNG, Cypress (API), REST Assured
• Скорость: Медленнее, чем unit (секунды)
• Примеры: Тест процесса регистрации (форма → API → БД → email)

Системное тестирование

• Объект: Приложение целиком, как единая система
• Кто пишит: QA команда
• Инструменты: Selenium, Cypress, Playwright
• Скорость: Медленно (минуты)
• Примеры: Полный workflow покупки, весь процесс создания профиля

Acceptance-тестирование (UAT)

• Объект: Соответствие требованиям бизнеса
• Кто делает: Пользователи, бизнес-аналитики
• Критерий: Требования выполнены ✓
• Примеры: Клиент проверяет, что отчёт выглядит правильно

Классификация по виду функциональности

Функциональное тестирование

Проверка того, что приложение делает то, что обещает:

• Корректность логики
• Правильность вычислений
• Валидация входных данных
• Обработка ошибок

Нефункциональное тестирование

Performance Testing:

• Время отклика API (< 200ms)
• Пропускная способность (requests per second)
• Потребление памяти
• Утечки памяти

Security Testing:

• SQL injection
• XSS атаки
• CSRF защита
• Аутентификация/авторизация
• Шифрование данных

Usability Testing:

• Удобство интерфейса
• Понятность навигации
• Доступность для людей с ограничениями

Compatibility Testing:

• Разные браузеры (Chrome, Firefox, Safari, Edge)
• Разные ОС (Windows, Mac, Linux)
• Разные устройства (мобила, планшет, десктоп)
• Разные версии библиотек

Reliability Testing:

• Стабильность при длительной работе
• Восстановление после сбоев
• Обработка сбоев сети

Классификация по белизне ящика (Box Testing)

Black Box Testing (Чёрный ящик)

• Подход: Тестирование без знания внутреннего кода
• Фокус: Входы и выходы
• Кто делает: QA
• Пример: Отправляю форму → проверяю результат в UI

White Box Testing (Белый ящик)

• Подход: Тестирование с полным знанием кода
• Фокус: Логика, граничные условия, ветвления
• Кто делает: Разработчики (unit тесты)
• Пример: Проверяю все ветки if/else, исключительные ситуации

Grey Box Testing (Серый ящик)

• Подход: Частичное знание архитектуры
• Пример: Знаю, что есть API, но не знаю код → тестирую API с разными параметрами

Классификация по подходу и целям

Smoke Testing (Дымовое тестирование)

• Цель: Быстро проверить, что основной функционал работает
• Время: 30 минут
• Сценарии: 5-10 критических путей
• Когда: После каждой сборки

Sanity Testing

• Цель: Проверить логику конкретного модуля
• Время: 1-2 часа
• Когда: После исправления бага

Exploratory Testing

• Подход: Без плана, импровизированное тестирование
• Навык: Требует опыта и интуиции
• Результат: Находит неожиданные баги
• Мой опыт: В 20% случаев находит критические проблемы, которые пропустили плановые тесты

Negative Testing

• Цель: Проверить, как система обрабатывает ошибки и невалидные входы
• Примеры:
  • Отправить форму с sql injection
  • Очень большие числа
  • Пустые поля
  • Специальные символы

Positive Testing

• Цель: Проверить happy path, нормальный сценарий
• Пример: Логин с верными креденшалами → успешная аутентификация

Классификация по охвату

Full Regression

Тестирование всей системы целиком

• Время: Может занять недели
• Когда: Перед мажорными релизами

Partial Regression

Тестирование затронутых модулей и их зависимостей

• Время: Несколько часов-дней
• Когда: Перед каждым спринтом

Progressive Testing

Тестирование только новых функций и их взаимодействия с существующей функциональностью

Классификация по автоматизации

Ручное тестирование

• Плюсы: Гибкость, требует меньше подготовки
• Минусы: Медленно, подвержено человеческой ошибке
• Хорошо для: Exploratory, UI/UX, сложная логика

Автоматизированное тестирование

• Плюсы: Быстро, повторяемо, масштабируемо
• Минусы: Требует инвестиций, нужны навыки программирования
• Хорошо для: Регрессия, данные, API, сценарии с известным результатом

Мой балансировка в практике

Пирамида тестирования:

• 60% Unit тесты (быстро, дешево, пишут разработчики)
• 30% Интеграционные тесты (средняя скорость)
• 10% E2E тесты (медленно, дорого, но проверяют реальный user flow)

Автоматизация:

• 100% — Unit и интеграционные
• 70% — System (критические пути)
• 30% — Exploratory (ручное)

Выбор классификации зависит от:

• Типа приложения (веб, мобил, desktop)
• Требований к качеству
• Времени и бюджета
• Этапа разработки (спринт vs pre-release)

Квалифицированный QA должен использовать все эти классификации комплексно для обеспечения максимального качества за разумное время.