Контекст

Перед тем как писать тест-кейсы или баг-репорты, junior QA должен ответить себе на вопрос: что именно мы защищаем? Без понимания «качества» тестирование превращается в механическое кликанье без цели.

Компании теряют деньги и репутацию из-за дефектов, выявленных пользователями, а не QA.
QA-инженер — это не «человек, который ломает программы»; его цель — не допустить, чтобы проблемы добрались до пользователя.
Понять роль QA = понять, ради чего ты приходишь на работу каждый день.

Рабочий алгоритм

Используй следующий мысленный алгоритм при оценке качества любого продукта или фичи:

Шаг 1. Определи ожидания: что пользователь или бизнес считают правильным поведением системы?
Шаг 2. Сравни с реальностью: как продукт ведёт себя на самом деле?
Шаг 3. Оцени соответствие стандартам: соблюдены ли нормы безопасности, производительности, доступности?
Шаг 4. Учти контекст: кто пользователь, каковы условия эксплуатации (медленный интернет, мобильный браузер)?
Шаг 5. Сформулируй риски: что произойдёт, если это не починить до релиза?

Пример из практики

Интернет-магазин выпустил обновление корзины. Кнопка «Оформить заказ» отображается на десктопе, но исчезает на iPhone SE (320px). QA-инженер применяет алгоритм: — Ожидание: кнопка доступна на всех поддерживаемых устройствах (требование в спецификации). — Реальность: кнопка не видна на экране шириной 320px. — Стандарт: адаптивный дизайн — явное требование проекта. — Контекст: 18% пользователей заходят с устройств <375px согласно аналитике. — Риск: почти каждый пятый пользователь не может оформить заказ → прямые потери выручки. Мини-баг-репорт (фрагмент): ``` Title: Кнопка «Оформить заказ» не отображается на iPhone SE (320×568) Steps: 1. Открыть корзину. 2. Уменьшить браузер до 320px. Expected: кнопка видна и кликабельна. Actual: кнопка полностью скрыта за пределами viewport. Severity: Critical | Priority: P1 ```

Частые ошибки

Начинающие QA-инженеры допускают ряд типичных заблуждений о качестве и своей роли:

«Моя задача — найти как можно больше багов.» — Нет. Задача — снизить риск выхода некачественного продукта. Иногда один критичный баг важнее тридцати косметических.
«Качество = отсутствие багов.» — Продукт без дефектов, но медленный, неудобный или небезопасный — не качественный.
«QA проверяет только в конце разработки.» — Современный QA вовлечён с момента написания требований.
«Разработчик сам должен проверить свой код.» — Разработчик проверяет, но QA приносит независимый взгляд и системное покрытие.

✅ Самопроверка

1Назови три атрибута качества ПО помимо «отсутствия багов».

Например: производительность (скорость отклика), удобство использования (UX), безопасность, надёжность (доступность), совместимость с устройствами и браузерами.

2В чём главная цель QA-инженера?

Снизить риск попадания некачественного продукта к пользователю, а не просто найти максимальное количество дефектов.

3На каком этапе разработки QA должен включаться в работу над продуктом?

С самого начала — уже при анализе и написании требований, а не только при финальном тестировании.

4Почему независимый взгляд QA ценен, даже если разработчик сам тестирует свой код?

Разработчик склонен проверять так, как он задумал; QA проверяет как пользователь и ищет неочевидные сценарии, упущенные при реализации.