TL;DR
- Тестирование ПО проверяет, что софт работает как ожидается и соответствует потребностям пользователей
- Типы тестирования: функциональное, нефункциональное, ручное, автоматизированное, черный ящик, белый ящик
- Дизайн тест-кейсов: классы эквивалентности, граничные значения, таблицы решений
- STLC (Software Testing Life Cycle): требования → планирование → дизайн → выполнение → отчетность
- Код не нужен для старта — ручное тестирование — это полноценный карьерный путь
Подходит для: Людей, рассматривающих карьеру в QA, разработчиков, желающих понять тестирование, проектных менеджеров Пропусти, если: Ты уже практикующий тестировщик, ищущий продвинутые техники Время чтения: 12 минут
Ты нашел баг в продакшене. Пользователи жалуются. Команда разработки в панике. Все спрашивают: “Как это прошло через тестирование?”
Этот туториал учит основам тестирования ПО — концепциям, техникам и процессам, которые предотвращают попадание багов к пользователям.
Что такое тестирование ПО?
Тестирование ПО — процесс оценки приложения для:
- Поиска дефектов — баги, ошибки, неожиданное поведение
- Верификации требований — делает ли оно то, что должно?
- Валидации качества — достаточно ли оно хорошо для пользователей?
Тестирование — это не просто “кликанье по кнопкам”. Это систематическая дисциплина с техниками, процессами и специализированными знаниями.
Почему тестирование важно
| Без тестирования | С тестированием |
|---|---|
| Баги в продакшене | Баги пойманы рано |
| Злые пользователи | Довольные пользователи |
| Дорогие исправления | Дешевые исправления |
| Утечки безопасности | Безопасность проверена |
| Потерянный доход | Защищенный доход |
Стоимость багов растет со временем:
- Баг найден в требованиях: $1 на исправление
- Баг найден в разработке: $10 на исправление
- Баг найден в тестировании: $100 на исправление
- Баг найден в продакшене: $1000+ на исправление
Типы тестирования ПО
По подходу
Ручное тестирование
- Тестировщик выполняет тесты вручную
- Лучше для: исследовательского тестирования, юзабилити, сложных сценариев
- Код не требуется
Автоматизированное тестирование
- Скрипты выполняют тесты автоматически
- Лучше для: регрессии, повторяющихся тестов, CI/CD
- Требует навыков программирования
По знанию кода
Тестирование черного ящика
- Тестирование без знания внутреннего кода
- Фокус на входах и выходах
- Большинство ручного тестирования — черный ящик
Тестирование белого ящика
- Тестирование с полным доступом к коду
- Анализ покрытия, путей кода
- Обычно выполняется разработчиками
Тестирование серого ящика
- Частичное знание внутренностей
- Тестирование БД, API тестирование
- Распространено в интеграционном тестировании
По уровню
┌─────────────────────────────────────┐
│ E2E / Системные тесты │ ← Полные user flows
├─────────────────────────────────────┤
│ Интеграционные тесты │ ← Взаимодействие компонентов
├─────────────────────────────────────┤
│ Юнит-тесты │ ← Отдельные функции
└─────────────────────────────────────┘
Жизненный цикл тестирования (STLC)
1. Анализ требований
- Изучение требований/user stories
- Определение, что нужно тестировать
- Уточнение неясностей с заинтересованными сторонами
2. Планирование тестирования
- Определение стратегии тестирования
- Оценка усилий и ресурсов
- Определение необходимых инструментов
3. Дизайн тестов
- Написание тест-кейсов
- Создание тестовых данных
- Проектирование тестовых сценариев
4. Выполнение тестов
- Запуск тест-кейсов
- Логирование результатов (pass/fail)
- Отчеты о найденных багах
5. Отчетность
- Сводка результатов тестирования
- Статистика багов
- Метрики покрытия
6. Закрытие
- Извлеченные уроки
- Архивирование тестовых артефактов
Написание тест-кейсов
Тест-кейс — набор условий для проверки корректности работы функции.
Шаблон тест-кейса
Test Case ID: TC-LOGIN-001
Название: Успешный логин с валидными credentials
Приоритет: Высокий
Предусловия: Аккаунт пользователя существует, пользователь разлогинен
Шаги:
1. Перейти на страницу логина
2. Ввести валидный email: user@example.com
3. Ввести валидный пароль: Password123
4. Нажать кнопку Login
Ожидаемый результат: Пользователь перенаправлен на dashboard, показано welcome-сообщение
Фактический результат: [Заполняется при выполнении]
Статус: [Pass/Fail]
Техники дизайна тестов
Классы эквивалентности
Разделение входных данных на группы (разделы), которые должны вести себя одинаково.
Пример: Поле возраста (валидно: 18-120)
Раздел 1: Невалидно (< 18) → Тест с 17
Раздел 2: Валидно (18-120) → Тест с 50
Раздел 3: Невалидно (> 120) → Тест с 121
Анализ граничных значений
Баги часто возникают на границах. Тестируй края.
Пример: Поле возраста (валидно: 18-120)
Тест: 17 (чуть ниже минимума) → Невалидно
Тест: 18 (минимальная граница) → Валидно
Тест: 19 (чуть выше минимума) → Валидно
Тест: 119 (чуть ниже максимума) → Валидно
Тест: 120 (максимальная граница) → Валидно
Тест: 121 (чуть выше максимума) → Невалидно
Таблицы решений
Когда несколько условий влияют на результат.
Пример: Логин с 2FA
| Условие | R1 | R2 | R3 | R4 |
|--------------------|----|----|----|----|
| Валидный пароль | Y | Y | N | N |
| Валидный 2FA код | Y | N | Y | N |
|--------------------|----|----|----|----|
| Доступ разрешен | Y | N | N | N |
| Сообщение об ошибке| N | Y | Y | Y |
Отчеты о багах
Шаблон баг-репорта
Bug ID: BUG-2024-001
Название: Логин не работает с валидными credentials на Chrome mobile
Severity: High
Priority: Critical
Окружение: Chrome 120, Android 14
Шаги воспроизведения:
1. Открыть приложение в Chrome mobile
2. Ввести валидный email: user@example.com
3. Ввести валидный пароль: Password123
4. Нажать кнопку Login
Ожидаемо: Редирект на dashboard
Фактически: Сообщение об ошибке "Something went wrong"
Вложения: screenshot.png, video.mp4
Карьерный путь в тестировании ПО
Entry Level (0-2 года)
├── Ручной тестировщик
├── QA Аналитик
└── Тест-инженер
Mid Level (2-5 лет)
├── Senior QA Инженер
├── Инженер автоматизации
├── Тестировщик производительности
└── Тестировщик безопасности
Senior Level (5+ лет)
├── QA Lead / Manager
├── Тест-архитектор
├── QA Director
└── Principal QA Engineer
AI-Assisted тестирование
AI меняет подход к тестированию ПО.
Что AI делает хорошо:
- Генерация тест-кейсов из требований
- Визуальное регрессионное тестирование
- Предсказание высокорисковых областей
- Анализ паттернов результатов тестов
Что всё ещё требует людей:
- Решения о стратегии тестирования
- Понимание бизнес-контекста
- Исследовательское тестирование
- Оценка юзабилити
FAQ
Что такое тестирование ПО?
Тестирование ПО — процесс оценки программного обеспечения для поиска дефектов, проверки соответствия требованиям и пригодности для пользователей. Включает различные активности: написание тест-кейсов, выполнение тестов, отчеты о багах и верификацию исправлений.
Можно ли стать тестировщиком без программирования?
Да. Карьера ручного тестировщика не требует программирования. Ты будешь писать тест-кейсы, выполнять тесты, отчитываться о багах — всё без кода. По мере роста базовые скрипты (SQL, простая автоматизация) помогают, но не обязательны.
В чем разница между QA и тестированием?
Тестирование — подмножество QA. Тестирование находит баги в существующем ПО через выполнение и верификацию. QA (Quality Assurance) шире: это предотвращение дефектов через улучшение процессов, стандарты, ревью и раннее участие в разработке.
Сколько времени нужно, чтобы стать тестировщиком?
Сроки зависят от роли:
- Ручное тестирование entry-level: 2-3 месяца целенаправленного обучения
- Автоматизация тестирования: 6-12 месяцев (включая основы программирования)
- Senior роли: 3-5 лет практического опыта
Официальные ресурсы
Смотрите также
- Пирамида автоматизации тестирования - Баланс юнит, интеграционных и E2E тестов
- API Testing Tutorial - Тестирование REST API от основ до автоматизации
- BDD: От требований к автоматизации - Руководство по Behavior-Driven Development
- QA Interview Questions - Подготовка к собеседованиям тестировщиков
