Расскажи про свой опыт взаимодействия с тестировщиками

Опыт взаимодействия System Analyst'а с тестировщиками (QA)

Это один из ключевых relationships в разработке. За 10+ лет я научился строить её правильно.

Моя роль как аналитика во взаимодействии с QA

1. На этапе анализа требований

Что я делаю:

• Вовлекаю QA с самого начала (не в конце!)
• Вместе с ними разрабатываю сценарии тестирования
• Спрашиваю: "Как ты будешь это тестировать?"
• Слушаю их опасения по поводу testability

Пример:

Я: "Нам нужна система с автоматическим payment processing" QA: "А как я тестировать если real payment gateway стоит 100$?" Я: "Хороший вопрос. Давайте требуем mock gateway для тестов"

Это спасает недели переделок потом.

2. На этапе написания требований

Acceptance Criteria должны быть testable:

НЕПРАВИЛЬНО:

"Система должна быть быстрой"
"Интерфейс должен быть удобным"
"Обработка платежей должна быть безопасной"

ПРАВИЛЬНО:

✓ Время загрузки страницы < 2 сек (измеримо через DevTools)
✓ Основная задача выполняется за 3 клика (можно проверить)
✓ Платежная информация передаётся только по HTTPS (проверить в Network tab)

QA должен понимать КОНКРЕТНО, что проверять.

3. Во время разработки

Общение с QA:

Есть дефект:

QA: "Feature X сломалась" Я: "Это баг или это не соответствует требованиям? Давай посмотрим requirement."

Часто выясняется:

• Это вообще не баг, а неправильное понимание
• Это баг в требервании, которое я неправильно описал
• Это реальный баг в коде разработчика

Классификация проблем:

Тип 1: Bug (код делает не то, что написано)
  → Developer должен чинить

Тип 2: Requirement issue (требование непонятно)
  → Я должен уточнить

Тип 3: Design issue (дизайн не соответствует requirement)
  → Нужна встреча: я + разработчик + дизайнер

Тип 4: Business issue (requirement не соответствует бизнесу)
  → Нужна встреча с Product Owner

4. На этапе тестирования (QA тестирует систему)

Что я делаю:

• Всегда присутствую на UAT (User Acceptance Testing)
• QA тестирует функциональность, я проверяю что это соответствует требованиям
• Приоритизирую баги вместе с QA: что надо чинить перед production, что может подождать

Пример приоритизации:

P0 (Critical, чинить сейчас):
- Платёж не проходит → деньги теряются
- Данные теряются при сохранении

P1 (High, чинить до production):
- Интерфейс отображается неправильно на мобильном
- Очень медленное выполнение (> 5 сек)

P2 (Medium, можно в next версию):
- Небольшая typo в сообщении
- Крайне редкий edge case

P3 (Low, может быть и не чинится):
- Интерфейс не очень красивый
- Suggestion, которую 1% пользователей будет использовать

Реальные примеры конфликтов и как их решал

Конфликт 1: QA говорит "это баг", разработчик говорит "это фиче"

Сценарий:
QA: "Когда я создаю Order без customer email, система создаёт заказ
без email. Это баг."
Dev: "Нет, это design. Email опциональный."
Меня спрашивают что делать.

Решение:
Я открыл requirement:
"Requirement UR-001 говорит: Email обязателен (NOT NULL)"

Значит это БАГ, dev должен чинить.

Альтернатива: если бы требование говорило "email опциональный",
то это не баг, QA ошибается.

Ключ: требование — source of truth.

Конфликт 2: QA находит проблему, но разработчик говорит "это не в scope"

Сценарий:
QA: "На iPad Safari, если сделать landscape, кнопка пропадает"
Dev: "Мы не тестировали на Safari. В scope только Chrome/Firefox."
Я:

1. Проверяю requirement: есть ли требование про Safari?
2. Если есть → dev должен чинить (в scope)
3. Если нет → это technical debt, не срочно

Если нет, я помогаю приоритизировать:
"Это 5% наших пользователей, можем отложить в v2.0"
Документирую в known issues.

Конфликт 3: QA говорит "это слишком сложно тестировать"

Сценарий:
QA: "Как я тестировать сложную workflow с 20 шагами и разными
branch'ами? Это невозможно вручную."

Мое решение:
1. Сразу говорю разработчику: "Это требует automation"
2. Пишу требование: "System должна иметь API для automation тестов"
3. Разработчик добавляет test endpoints
4. QA пишет automated tests

Это экономит недели работы QA на повторяющиеся тесты.

Лучшие практики взаимодействия

Встречи:

• Еженедельный синк: Я + QA + DevLead (30 мин)
• Обсуждаем progress, блокеры, приоритеты
• Четко определяем что готово, что ещё тестируем

Документация:

• Я пишу Test Cases на основе Acceptance Criteria
• QA добавляет edge cases которые я не предусмотрел
• Документ живой — обновляем когда меняются требования

Коммуникация:

Хорошо: "According to UR-005 requirement, this is a bug"
Плохо: "Это явно баг"

Хорошо: "QA правильно нашёл проблему. Это соответствует требованию X."
Плохо: "QA ошибается. Это не баг."

Частые проблемы и как я их решаю

Проблема 1: QA тестирует не то что надо

QA тестирует функцию, которая не в требовании

Решение:

• Регулярно align на requirement
• Дать QA checklist: "Тестируй ровно эти 10 пунктов"
• Не дополнительный scope без согласования

Проблема 2: Requirement слишком размыто

Я написал: "Система должна быть надежной" QA спрашивает: "Как я это тестировать?"

Решение:

• Переписать в метрики: "99.9% uptime", "< 0.1% error rate"
• Дать инструменты для измерения

Проблема 3: QA находит баги слишком поздно (перед production)

Неделю до launch QA находит критичный баг

Решение:

• Testing начинается с первого дня разработки (не в конце)
• Требование к разработчикам: unit tests
• QA начинает тестировать как только feature в dev environment

Проблема 4: QA тестирует вручную то что можно автоматизировать

QA 3 дня тестирует все поля формы вручную

Решение:

• Требование: automated tests для regression (повторяющихся проверок)
• QA только на новые feature и exploratory testing
• Сэкономили 80% time on repetitive tasks

Что должен знать QA от меня (аналитика)

Я убеждаюсь, что QA понимает:

1. Бизнес-контекст

   • Почему эта фиче нужна
   • Какие пользователи используют
   • Какие метрики сукцеса

2. Требования

   • Acceptance criteria понятны
   • Граничные случаи (edge cases)
   • Что НЕ входит в scope

3. Риски

   • Что может сломаться
   • Что критично
   • Что можно отложить

4. Инструменты

   • Как тестировать
   • Какие инструменты доступны
   • Как логировать баги

Тон коммуникации

Важный момент: QA — мой союзник, не противник.

Да, они находят баги в нашей работе. Но это хорошо, потому что:

• Лучше найти баг в тестировании, чем в production
• Они защищают качество продукта
• Вместе мы делаем хороший результат

Что я говорю:

✓ "Спасибо, что нашёл этот edge case. Я переделаю requirement."
✓ "Это хороший вопрос. Давайте обсудим с Product Owner."
✓ "QA абсолютно прав. Это баг в коде. Dev, чинишь?"

Что не говорю:

✗ "Это не баг, это фиче"
✗ "QA плохо тестирует"
✗ "Это не в scope"

Вывод

Удачное взаимодействие с QA — это не управление ими, это ПАРТНЁРСТВО:

• Я даю ясные требования
• QA дают ясные баги
• Вместе определяем что это (баг, требование issue или design issue)
• Вместе приоритизируем
• Вместе достигаем качество

Система Analyst'ов, которые хорошо работают с QA, создают продукты в 3 раза лучшего качества, чем те, которые игнорируют QA.