Раздел: 01 — Основы тестирования ISTQB CTFL v4.0, Глава 1.5 Уровень: Beginner Ссылка:ISTQB CTFL v4.0
Введение
Хороший тестировщик — это не просто «человек, который кликает по кнопкам». ISTQB выделяет три категории навыков, которые необходимы для эффективного тестирования: технические, тестовые и мягкие навыки. Разберём каждую.
Технические навыки позволяют тестировщику понимать, как устроена система изнутри, работать с инструментами и автоматизировать рутину.
Ключевые навыки
1. Понимание архитектуры ПО
Тестировщик должен понимать базовые концепции: клиент-сервер, API, базы данных, микросервисы. Это помогает проектировать тесты глубже UI.
Пример: Зная, что мобильное приложение общается с backend через REST API, тестировщик может проверить ответ API напрямую (Postman), не дожидаясь UI, и быстрее изолировать проблему.
2. Работа с базами данных
Умение писать SQL-запросы позволяет проверять данные «под капотом».
Пример: После создания заказа тестировщик проверяет не только UI, но и данные в БД: SELECT * FROM orders WHERE user_id = 123 ORDER BY created_at DESC LIMIT 1. Оказывается, поле total сохраняется как NULL — баг, который UI не показывает.
3. Работа с инструментами
Категория
Инструменты
Баг-трекинг
Jira, YouTrack, Linear, Azure DevOps
Тест-менеджмент
TestRail, Zephyr, Allure TestOps
API-тестирование
Postman, Swagger, curl
Автоматизация
Selenium, Playwright, Appium, pytest
DevTools
Chrome DevTools, Network tab, Console
Версионирование
Git, GitHub, GitLab
4. Основы программирования
Даже без глубоких знаний программирования, тестировщику полезно:
Читать код на уровне понимания логики
Писать простые скрипты для генерации тестовых данных
Понимать CI/CD-пайплайны
Пример: QA Engineer пишет Python-скрипт для генерации 10 000 тестовых пользователей с разными комбинациями данных. Ручной ввод занял бы дни.
Категория 2: Тестовые навыки (Testing Skills)
Описание
Тестовые навыки — это специфические компетенции, которые отличают тестировщика от разработчика или аналитика.
Ключевые навыки
1. Тест-дизайн (Test Design)
Умение проектировать тесты так, чтобы максимальное покрытие при минимальном количестве тестов.
Пример: Поле «Возраст» принимает значения 0–120. Вместо проверки каждого значения, тестировщик использует граничные значения: -1, 0, 1, 59, 60, 119, 120, 121. Восемь тестов вместо 122.
2. Анализ дефектов (Defect Analysis)
Умение не просто найти баг, но понять его причину и область влияния.
Пример: Баг: кнопка «Оплатить» не работает. Неопытный тестировщик пишет: «Кнопка не работает». Опытный: «При нажатии «Оплатить» при сумме заказа > 10000 ₽ и выбранном способе оплаты «Карта» — JS-ошибка в console: TypeError: Cannot read property 'id' of undefined. Воспроизводится в Chrome 120, Firefox 121. Не воспроизводится в Safari.»
3. Exploratory Testing
Структурированное исследование системы без заранее написанных тест-кейсов. Тестировщик одновременно учится, проектирует и выполняет тесты.
Пример: Новый функционал — система рекомендаций товаров. Тестировщик исследует: «Что если я добавлю в корзину 50 товаров? А если удалю куки? А если переключу язык во время рекомендации?» — и находит 3 бага, которые формальные тесты не покрыли.
4. Планирование тестирования
Умение оценить объём работ, расставить приоритеты и составить реалистичный план.
Пример: Тестировщик оценивает regression за 3 дня. Менеджер просит за 1 день. Тестировщик демонстрирует: 200 тестов × 15 минут = 50 часов = 3 дня для одного человека. Предлагает автоматизировать smoke-тесты и сократить regression до 1.5 дней.
Категория 3: Мягкие навыки (Soft Skills)
Описание
Мягкие навыки — это то, что отличает хорошего тестировщика от просто компетентного. ISTQB выделяет три ключевых мягких навыка.
1. Коммуникация (Communication)
Почему важно
Тестировщик — коммуникационный хаб: он общается с разработчиками, аналитиками, менеджерами, пользователями. Непонятный баг-репорт = потеря времени. Конфликтный тон = напряжение в команде.
Что включает
Ясное написание: баг-репорты, тест-планы, отчёты — должны быть понятны с первого прочтения
Дипломатичная обратная связь: «Я нашёл проблему в твоём коде» → «Я заметил поведение, которое может не соответствовать ожиданиям пользователя»
Активное слушание: слушать не только слова, но и контекст, подтекст, невысказанное
Тестировщик находит критический баг за день до релиза. Вместо «Релиз невозможен, всё сломано» он пишет стейкхолдерам: «Обнаружен дефект в модуле оплаты: при определённых условиях транзакция завершается успешно, но деньги не списываются. Влияние: потенциальная потеря выручки. Рекомендация: перенести релиз на 2 дня, исправление — 4 часа работы.»
2. Критическое мышление (Critical Thinking)
Почему важно
Тестировщик должен сомневаться во всём: требованиях, дизайне, коде, собственных предположениях. Критическое мышление помогает задавать правильные вопросы и находить скрытые проблемы.
Что включает
Сомнение в очевидном: «Кнопка работает» → «А что если нажать дважды? А если во время загрузки?»
Поиск предположений: «Мы предполагаем, что пользователь всегда авторизован» → «А что если токен истёк?»
Анализ рисков: «Насколько вероятен этот сценарий и каковы последствия?»
Проверка логики: «Требование говорит X, но логика подсказывает Y»
Что если ошибка на стороне банка, а не нашего сервиса?
Что если деньги списались, но ответ не пришёл?
Что если пользователь нажмёт «Оплатить» повторно?
Какое сообщение увидит пользователь через час? Через сутки?
Каждый вопрос находит реальный баг.
3. Любознательность (Curiosity)
Почему важно
Любознательный тестировщик не останавливается на проверке «по сценарию». Он исследует, экспериментирует, задаёт вопросы «а что если?» — и находит баги, которые формальные тесты не покрывают.
Что включает
Исследование системы за пределами тест-кейсов
Задавание вопросов: «Почему так? А что будет если?»
Интерес к технологиям: изучение новых инструментов, подходов, доменов
Эмпатия к пользователю: «Как реальный пользователь будет использовать это?»
Пример из жизни
Тестировщик тестирует форму обратной связи. По тест-кейсу — вводит текст и нажимает «Отправить». Но ему интересно:
Что если вставить 10 000 символов? → Система падает (баг)
Что если вставить эмодзи? → Отображается кракозябры (баг)
Что если отправить форму дважды быстро? → Создаются 2 тикета (баг)
Что если вставить SQL-инъекцию? → ... (security-тестирование)
Whole-Team Approach (Командный подход)
Описание
ISTQB подчёркивает, что качество — ответственность всей команды, а не только тестировщика. Whole-Team Approach объединяет навыки разных ролей для достижения общей цели.
Принципы
Общая ответственность за качество — каждый участник команды вносит вклад
Кросс-функциональные навыки — разработчики понимают тестирование, тестировщики понимают код
Постоянная обратная связь — короткие итерации, быстрое обнаружение проблем
Коллективное принятие решений — команда вместе определяет Definition of Done, приоритеты
Как это работает
Роль
Вклад в качество
Developer
Юнит-тесты, code review, тестируемость
QA Engineer
Интеграционные и E2E тесты, exploratory testing
Product Owner
Чёткие acceptance criteria, приоритеты
Designer
Проверка usability, accessibility
DevOps
Стабильная тестовая среда, CI/CD
Пример из жизни
В команде разработки мобильного банка:
Developer пишет юнит-тесты на модуль переводов (покрытие 80%)
QA Engineer проектирует E2E-тесты и проводит exploratory testing
Product Owner формулирует acceptance criteria: «Перевод проходит за ≤ 3 секунды, при ошибке — понятное сообщение»
Designer проверяет, что ошибка отображается корректно на всех размерах экрана
DevOps настраивает staging-среду с реальными платёжными шлюзами
Результат: 95% критических дефектов найдены до релиза.
Сводная таблица навыков
Категория
Навыки
Пример применения
Технические
SQL, API, DevTools, Git, основы кода
Проверка данных в БД, тестирование API
Тестовые
Тест-дизайн, анализ дефектов, exploratory, планирование