tg-me.com/psychiatry_and_system_design/11
Last Update:
Заметок не было довольно долго — у нас с женой родился ребенок и у меня случилось увлекательное погружение в мир грязных ползунков и детского кала 😀 💩 Теперь же процессы управления моей жизнью как-то нормализовались и появилось время что-то написать.
Обсудим сегодня важный вопрос — выбор структуры команды тестирования (они же QA инженеры).
Есть три способа расположить QA внутри вашей компании:
1️⃣ Вариант 1. Отдельные команды разработки и отдельная от них команда тестирования. Разработчики закончили работу над своим кодом, отдали фичу на проверку в другую команду. и пусть QA уже там с ней возятся. В этом случае, как правило, QA отбирает в релизы фичи, прошедшие тесты и формирует релиз-план новой версии программы.
2️⃣ Вариант 2. Специалисты тестирования являются частью продуктовой команды. Инженеры закончили разработку, передали фичи в тестирования специалистам QA внутри своей команды. После тестирования сама команда принимает решение о релизе и выпускает свой код в продакшн.
3️⃣ Вариант 3. QA нет, фичи тестируют сами же разработчики внутри команды. При описании этого способа часто звучат слова “quality assurance vs quality assistance” — вертикальные команды и сами инженеры несут непосредственную и полную ответственность за то, что они сделали.
Мое оценочное суждение — “Вариант 3” это неэффективная и опасная методология, которая приобрела популярность у некоторых менеджеров только из-за своей типа поэтичности (”мы несем ответственность за то, что делаем, у вас должен был ОВНЕРШИП 🙀”). Причин этой опасности и неэффективности две.
Причина первая — устройство нашего человеческого мозга 🧠 Если ты что-то строишь, то психологически не можешь взять результаты своего труда и как следует несколько раз ударить их с размаху об стену, чтобы посмотреть, как твое творение выдержит такой стресс-тест. А еще есть когнитивная ошибка искажения — мы все склонны искать подтверждения того, что правильно сделали свою работу, тогда как QA должны стараться доказать, что в работе есть ошибки. Короче, мозг не позволяет нам тестировать свой код на полную и хорошо.
Причина вторая — финансы 💸 Разработчики и QA специалисты обладают разными квалификациями. Хорошие разработчики организуют паттерны, базы данных, шины и файловые хранилища. Хорошие QA делают фаззинг, манки тестинг, нагрузочное тестирование, автоматические и ручные проверки. Просить людей из первой группы хорошо делать работу людей второй группы — экономически бессмысленно.
Вариант 3️⃣ — дорогой, полный когнитивных искажений и эмоциональных проблем способ выпускать софт, которые потенциально содержит баги.
Поэтому при организации структуры QA отдела мы всегда выбираем между “отдельная команда” и “интегрированные QA специалисты внутри других команд” (кстати, можно выбрать сразу два варианта, когда часть тестов делается внутри продуктовой команды и часть — снаружи).
Чтобы выбрать структуру оптимально, нужно ответить на один вопрос: “Должна ли наша компания релизить фичи централизованно и одномоментно? Или можно выпускать их каждый день порциями по чуть-чуть?”. Если должна — то нужно построить отдельную QA команду, если нет — то оптимальным решением будет внедрять QA в продуктовые команды.
На сегодня все, обнял-приподнял, всех с наступающими праздниками 🎉
BY Психиатрия и системный дизайн
Warning: Undefined variable $i in /var/www/tg-me/post.php on line 280
Share with your friend now:
tg-me.com/psychiatry_and_system_design/11