Главное за урок

Тестировщик — это партнёр команды, а не «ловец багов». Качество продукта зависит не только от того, как ты тестируешь, но и от того, как ты общаешься. Тон, контекст и структура сообщения напрямую влияют на то, будет ли баг починен и как к тебе относятся в команде.

Три главных правила коммуникации: сразу контекст + вопрос в одном сообщении, факты вместо эмоций, предлагай следующий шаг.

Тестировщик — партнёр, а не охотник на баги

Баги — это следствие, а не цель QA. Задача тестировщика — помочь команде выпустить качественный продукт.

Неправильная установка	Правильная установка
«Моя цель — найти как можно больше багов»	«Моя цель — снизить риск попадания проблем в прод»
«QA vs Dev — у нас разные цели»	«QA и Dev — одна команда с общим результатом»
«Разработчик должен сам всё проверить»	«Тестировщик — независимый взгляд, который помогает»

Противостояние «QA vs Dev» разрушает команду и замедляет поставку. Когда стороны работают как партнёры, баги находятся раньше и с меньшими потерями.

Принцип «Не пишите привет»

«Привет» без вопроса — это асинхронный блокер. Получатель видит сообщение, ждёт продолжения, теряет фокус.

Правило: задавай вопрос сразу в одном сообщении с контекстом и целью.

Плохо	Хорошо
«Привет» → [пауза] → «У меня вопрос» → [пауза] → «Баг не воспроизводится»	«Привет, Иван! Баг #123 воспроизводится на iOS 17.4, Chrome 124. Можем ли уточнить — это известная проблема или стоит проверить дальше?»

Подробнее: neprivet.com

Структура хорошего сообщения

контекст → что сделал → конкретный вопрос

Пример плохого сообщения:

«Ты не починил баг #77, я всё ещё вижу проблему»

Пример хорошего сообщения:

«Привет! Баг #77 воспроизводится на iOS 17.4, Chrome 124 при шагах 1-3. Можем уточнить условия — на каком окружении проверял? Могу прислать видео воспроизведения»

Правила структуры:

Один вопрос — одно сообщение
Без контекста разработчик не может помочь быстро
Не отправляй три отдельных «Привет», «Вопрос», «У меня баг»

QA vs Dev: откуда берётся конфликт

Конфликт — не в личностях, а в структуре коммуникации.

Сторона	Психологическая ловушка
Разработчик	Воспринимает баг как критику своей работы
Тестировщик	Боится давления дедлайна, смягчает формулировки — баг остаётся незамеченным

Типичные статусы багов и что за ними стоит:

Статус	Что это значит на практике
«Not a bug / It's a feature»	Иногда честный ответ, иногда — отмазка без объяснений
«Cannot reproduce»	Разработчик мог не попытаться воспроизвести в нужном окружении
«Won't fix / Low priority»	Решение принимается на уровне менеджмента или продукта
«By design»	QA может не согласиться — нужно уточнить требования и эскалировать

Правило: сначала факты, потом выводы. Не «ты не починил», а «баг воспроизводится при шагах X на окружении Y».

Формула SBI — конструктивная обратная связь

SBI — способ описывать проблемы без обвинений.

Шаг	Расшифровка	Пример
S — Situation	Конкретная ситуация	«На регрессии #45 я проверял форму регистрации»
B — Behaviour	Поведение системы	«При вводе email без @ форма принимает значение»
I — Impact	Последствия	«Пользователь создаёт аккаунт с невалидным email, письмо не приходит»

Как говорить о проблемах без скандала:

Заменяй «ты сломал» на «функциональность не работает как ожидалось»
Добавляй конкретику: версия, шаги воспроизведения, ожидаемый vs фактический результат
Предлагай следующий шаг: «Могу уточнить — это намеренное поведение или создать задачу?»

Встречи: дейли, планирование, ретроспектива

Дейли (ежедневный стендап)

Дейли — не отчёт «что я сделал», а синхронизация о блокерах и зависимостях.

Что говорит QA на дейли:

Что тестирую прямо сейчас
Что заблокировано и от кого зависит
Что нужно от других участников

Если нечего сказать — значит нет блокеров. Это тоже важная информация — не молчи.

Планирование (Planning / Grooming)

На планировании QA задаёт вопросы по критериям готовности:

«Что считается готовым (Definition of Done)?»
«Какие крайние случаи нужно покрыть?»
«Есть ли зависимости от других сервисов?»

Ретроспектива

На ретро QA говорит не только о технических проблемах, но и о коммуникационных.

Мнение тестировщика на ретро — ценный взгляд со стороны качества. Не бойся его высказывать.

Ключевые тезисы для теста

Тестировщик — партнёр команды, а не «ловец багов»
Принцип «не пишите привет»: контекст + вопрос в одном сообщении
Структура хорошего сообщения: контекст → что сделал → конкретный вопрос
SBI: Situation — Behaviour — Impact; описывай проблему, не обвиняй человека
На дейли QA сообщает: что тестирует, блокеры, что нужно от других
На планировании QA задаёт вопросы по критериям готовности
«Cannot reproduce» не означает что баг не существует — нужно уточнить окружение
Конфликт QA vs Dev — не в личностях, а в структуре коммуникации
Качество — ответственность всей команды, а не только QA
Прямое общение с разработчиком эффективнее, чем только через трекер

Домашнее задание

Написать сообщение разработчику по ситуации: «баг закрыт без объяснений».

Критерии хорошего сообщения:

Структура SBI или контекст → что сделал → вопрос
Нет обвинений и эмоций
Есть конкретное предложение следующего шага
Есть вопрос, а не утверждение

Отправить результат в чат марафона.

Полезные ссылки

Запись эфира урока 21: youtube.com/live/14WelZhY3rs
Не пишите привет — neprivet.com
Чат марафона в Telegram
Канал @qabigtech

Урок 21. Софт-скилы тестировщика. Часть 1

Темы урока

Видео урока

Конспект урока