Home

Оригинальная публикация

Это третья статья из серии. В первой я разобрал 5 техник тест-дизайна, во второй - API и Security Testing на собеседованиях. Сегодня тема другая - не техническая. Хочу поговорить про роли в команде.

Недавно я попал на концерт симфонического оркестра. Сижу в зале, 80 музыкантов на сцене, всё серьёзно - скрипки, виолончели, духовые. И тут дирижёр поднимает палочку, зал затихает, и у меня в голове:

«Подожди... а зачем он вообще нужен? Они же все профессионалы. Ноты перед глазами. Каждый знает свою партию. Ну начните играть, чего ждать-то?»

И тут меня накрыло. Я же слышу такое каждый месяц на работе:

«Зачем нам QA? Разработчики сами протестируют.»

«Зачем менеджер? Мы сами разберёмся, мы же взрослые.»

Одна и та же логика. И там, и тут. Давайте разберу, почему она не работает.

Что будет, если убрать дирижёра

Уже пробовали

Вообще, оркестры без дирижёра - это не фантазия. В Москве в 1922 году скрипач Лев Цейтлин создал Персимфанс (Первый симфонический ансамбль) - оркестр без дирижёра. Идея красивая: равенство, никаких иерархий, все решают вместе.

И знаете что? Они реально играли хорошо. Получили звание «Заслуженный коллектив Республики», давали 70+ концертов в сезон. Дирижёр Отто Клемперер назвал их исполнение «Патетической» Чайковского «самым совершенным». По их примеру создавали оркестры в США и Германии.

Но была цена:

• Репетиции отнимали в разы больше времени - камерно-ансамблевые методы, бесконечные дискуссии по интерпретации.

• Роль дирижёра всё равно частично выполнял концертмейстер - сидел на возвышении лицом к оркестру.

• В 1932 году ансамбль закрыли (по политическим причинам, но это отдельная история).

То есть даже успешный пример «команды без руководителя» работал с оговорками: больше времени на синхронизацию и неформальный лидер всё равно появился.

Оркестр = команда разработки

Я для себя тогда в зале нарисовал такую табличку (мысленно, конечно):

Аналогия кривоватая, конечно, но суть ловит. Скрипач видит только свою партию. Гобоист - свою. Каждый играет хорошо. Но кто слышит, как всё звучит вместе? Дирижёр.

В IT то же самое. Фронтендер написал красивый компонент. Бэкендер - чистый API. А вместе оно не работает, потому что формат данных не совпадает. И кто это заметит? Точно не тот, кто писал свой кусок.

«Разработчики сами могут тестировать» - и другие дорогие заблуждения

Я такое  лышу постоянно. И каждый раз хочется спросить: «А вы когда-нибудь свой текст вычитывали сразу после написания? Много опечаток нашли?»

Слепота автора

Мозг дочитывает за вас. Написали «привте» - глаз видит «привет». Это не лень, так мозг работает.

С кодом всё один в один. Разработчик знает, как функция должна работать, и тестирует именно этот сценарий:

// Разработчик написал:
function divide(a, b) {
  return a / b;
}

// Разработчик проверяет:
divide(10, 2)  // 5. Работает, ок

// А QA проверяет:
divide(10, 0)     // Infinity. Упс
divide("abc", 2) // NaN. А валидация где?
divide(10)        // NaN. Забыли аргумент
Объяснить с

Разработчик проверил то, что задумал. QA проверил то, что может пойти не так. Разные задачи, разный взгляд.

Эффект IKEA

Есть такой психологический баг (да, у людей тоже баги): вам нравится то, что вы сделали сами. Собрали шкаф из IKEA - он для вас шикарный, хотя дверца не закрывается и одна полка кривая.

С кодом то же. Разработчик подсознательно ищет подтверждение, что всё работает. QA ищет подтверждение, что что-то сломано. Разный настрой, если хотите. Кто-то должен быть тем самым занудой, который говорит: «А если вот так?»

Стоимость бага

Точные множители зависят от проекта, но порядок подтверждается исследованиями IBM Systems Sciences Institute и NIST. Баг в проде - это не просто «пофиксим». Это откат, хотфикс, ночная смена, злые пользователи и пост в Twitter.

Из практики: на e-commerce проекте я нашёл баг в расчёте скидок. При определённой комбинации товаров скидка удваивалась. Разработчик тестировал с одним товаром - у него всё ок. Я добавил три товара с разными акциями - и привет, бесплатная доставка + двойная скидка. Если бы это ушло в прод, компания теряла бы деньги каждый день, и никто бы не понял почему.

«Зачем менеджер? Мы сами разберёмся»

Ага. Давайте посмотрим, что дирижёр делает на самом деле (спойлер: не просто машет палочкой).

Ничего из этого - не «перетащить таск в Jira». Но почему-то именно так многие представляют работу менеджера.

Три сценария без менеджера (все реальные)

«У нас нет блокеров»

Дейли. Все говорят «всё ок». Через неделю оказывается, что бэкенд сделал API с одним форматом дат, а фронт ожидал другой. Две недели работы коту под хвост. Менеджер бы это увидел на уровне задач ещё в понедельник.

«Мы же договорились»

Обсудили на кухне. «Давай сделаем так.» Через месяц: «Мы такого не обсуждали.» Нет менеджера - нет фиксации решений. В оркестре это как если бы музыканты договорились «играть побыстрее», но один ускорился на 10%, а другой на 30%.

«Мы сами расставим приоритеты»

Один разработчик хочет рефакторить. Второй - попробовать новый фреймворк. Третий - закрыть техдолг. Все по-своему правы. Но бизнесу нужна конкретная фича к пятнице. Без менеджера команда делает то, что интересно, а не то, что нужно.

А как же самоорганизация?

Да, работает. Но с нюансами.

Камерный квартет - 4 музыканта - прекрасно обходится без дирижёра. Они видят друг друга, слышат друг друга, реагируют мгновенно. Играют вместе годами.

Но когда квартет вырастает до оркестра - всё ломается.

Есть формула Брукса: число каналов коммуникации = n(n-1)/2. При 3 людях это 3 канала. При 12 - уже 66. При 20 - 190. Попробуйте синхронизировать 190 каналов без координатора. Удачи.

QA - не «тот, кто кликает кнопки»

Знаете, кто в зале самый внимательный слушатель? Музыкальный критик. Он сам не играет. Но он слышит то, чего не слышат музыканты: тромбон чуть опоздал, баланс между секциями поплыл, в третьей части темп уехал.

Музыканты этого не замечают - они внутри процесса. Критик слушает со стороны.

QA делает то же самое. Разработчик внутри кода. QA смотрит снаружи, как пользователь. И видит то, что изнутри не видно.

Случай из практики

На проекте перед релизом все были уверены: готово. Unit-тесты зелёные, code review пройден, каждый разработчик свой модуль проверил.

Я сел проходить E2E-сценарий. Зарегистрировался, выбрал курс, начал урок, дошёл до теста... и приложение легло. Причём падало только при определённой последовательности: именно этот курс, именно после этого урока, именно при первой попытке теста.

Ни один разработчик это бы не нашёл, потому что каждый тестировал только свой кусок. А пользователь проходит весь путь целиком.

Антипаттерны, которые я видел лично

«QA подключим в конце»

Дирижёр приходит на каждую репетицию, а не за час до концерта. В IT почему-то нормально подключить QA в последний день спринта: «Мы всё сделали, проверь до пятницы.» И потом удивляются, что релиз уезжает.

QA нужен с самого начала. Подход  называется Shift Left:

Плохо:Требования → Разработка → [в конце] QA → Релиз

Нормально:
Требования [+ QA] → Разработка [+ QA ревью] → Тестирование → Релиз

Когда QA читает требования на старте, он ловит противоречия до того, как написана первая строчка кода. Я так однажды нашёл, что два пункта в ТЗ друг другу противоречили - разработчики обнаружили бы противоречие только при мерже.

«Менеджер = надзиратель»

Плохой менеджер: «Почему задача не закрыта? Где отчёт? Обновите статус.»

Нормальный менеджер: «Вижу, что задача залипла - я поговорил с соседней командой, они разблокировали. Делайте спокойно, я разберусь с бизнесом.»

Разница - как между дирижёром, который тычет палочкой в каждую ошибку, и дирижёром, который ведёт за собой.

«Каждый сам себе QA»

Когда разработчик тестирует свой код, он:

• Пропускает edge cases (слепота автора, помните?)

• Торопится - «да я и так знаю, что работает»

• Проверяет реализацию, а не поведение

Unit-тесты отлично. Но это не замена QA. Как разминка не заменяет саму тренировку.

Когда QA и менеджер реально не нужны

Я не фанатик. Бывают ситуации, когда можно обойтись:

Без QA:

• MVP, хакатон, прототип

• 2-3 сеньора с хорошей культурой тестирования

• 95%+ покрытие автотестами и зрелый CI/CD

• Внутренний тул, который видят 5 человек

Без менеджера:

• Команда из 3-4 человек, которые давно вместе

• Понятный, стабильный скоуп

• Нет внешних заказчиков

• Все в курсе, зачем делают то, что делают

Но таких команд мало. Как камерных квартетов в мире музыки - единицы. Большинство проектов - это оркестр.

Как это выглядит, когда всё работает

На том концерте был один момент, который я запомнил. Переход между частями симфонии. Тишина. Пауза секунд пять. Потом дирижёр медленно поднял руки - и 80 человек вступили одновременно. Вот прям в одну долю секунды. Мурашки по коже.

Никакой магии. За всем стоят координация , доверие и понимание, кто за что отвечает.

В IT я видел такие моменты тоже. Когда перед дедлайном все синхронизированы: бэкенд готов, фронт подключился, QA проверил, менеджер согласовал с бизнесом. И фича уходит в прод без единого бага. Редко, но бывает. И бывает только когда каждый делает своё дело.

Вместо итогов

Команда без QA - это как оркестр, где никто не слушает общее звучание. Каждый играет свою партию хорошо, но вместе звучит так себе.

Команда без менеджера - это как оркестр без дирижёра. Можно, если вас четверо и вы вместе 10 лет. Но если вас 15 и проект сложный - будет каша.

Не потому что музыканты плохие. А потому что музыка - больше, чем набор правильных нот.

Если было полезно - плюсуйте. Расскажите в комментах, как у вас: есть выделенный QA и менеджер, или «сами справляемся»? Интересно послушать разный опыт. Следующая статья будет про System Design для QA.

Обсудить в форуме