Комментарии 9
Инженер проверяет сам себя. В принципе - неплохо, но лучше когда присутствует 4-eyes проверка, это снижает риск изначально неправильного понимания задачи и дальнейшей ее имплементации. Как вы от этого защищаетесь?
Про ревью сказано миллиард раз уже: дорого, плохо, вредно. Если смотреть в тему качества, то станет очевидным, что обеспечение выгоднее контроля. В этой статье про это как раз. https://hackernoon.com/code-review-its-bad-expensive-and-ineffective-in-most-cases
В эпоху развитого CI/CD фраза "стоимость ошибки сильно возрастает, если она пролезла в прод" не так уж и сильна. Далеко не всякие ошибки хоть как-то влияют на стоимость. Отозвать партию дисков из магазинов было дорого. Сейчас обновление на проме делает скрипт за секунду, он уже есть готовый и единичный его вызов практически бесплатен.
Если делать нормальный план откаты и в целом изменения небольшими кусками, которые можно откатить, то проблем не вижу.
Я про ревью ничего не писал. Я писал про то что, когда тест приходит писать другой человек (не автор имплементации) - это увеличивает шансы на корректную валидацию ПО.
По поводу что баги просто откатывать - технически да, но если речь идет о чувствительных вещах, типа неправильных начислений денежных средств, то страдают репутация, доверие. Мы же про банк говорим.
Привет, перед тем, как это внедрять мы вложились в автоматизацию. Разложили ее по пирамиде. Плюс в реализации автоматизации принимали полноценное участие, как QA, так и DEV. Поэтому все знали, какие проверки там есть, как с ними работать и какие добавлять. В целом это уберегло от роста багов, графики показывали, что качество не ухудшилось, а даже тренд на снижение нарисовался.
По поводу неправильного понимания задачи, мы запускали отдельный процесс по работе с анализом задач, чтобы снизить факторы неправильного понимания задачи.
В некоторых командах, мы попробовали схему полного (без аналитика) участия инженеров (QA и DEV) в анализе. Пробовали на несложных задачах". То есть было прямое взаимодействие QA или DEV с заказчиком. В целом эта схема тоже показали неплохие результаты.
А если бизнес будет сам сразу кодить и тестить это же вообще квинтисенция эффективности
Было бы здорово)) Только бизнес это не команда поставки и у них другие задачи, направленные на исследования/анализ бизнес среды и генерацию прибыльных стратегий.
А QA и DEV это прямые участники поставки. Инженеры базовая задача которых, поставлять бизнес ценность клиенту. Поэтому кажется тру подходом, что они все могут поставить ценность. Но роли у них остаются разными - QA - драйвит и обеспечивает качество, DEV - драйвит правильную архитектуру кода.
Исполнять тестирование и разработку, может каждый из них.
подход в целом интересный, спасибо за статью
скажите, удалось ли понять, за счет чего именно было достигнуто подобное повышение cycle tyme?QA вероятно ведь его замедлили, поскольку скорость разработки должна быть пониже, чем у полноценных разработчиков с опытом? метрика учитывает разработку и поддержку автоматизированных тестов?
если QA были бутылочным горлышком в потоке поставки, то почему бы не оставить их заниматься своими процессами и дальше, но подключив (обучив и тд, как вы и сделали) к этому разработку?
и отдельный момент - насколько различен уровень оплаты труда QA и разработчиков? учитывалась ли оптимальность бюджета команды, или упор был на ускорение поставки безотносительно цены вопроса?
Привет, спасибо за коммент!
Cycle Time ускорился за счет нескольких вещей:
быстрая обратная связь о результатах тестирования
нет лишней коммуникации с qa о результатах тестов
самостоятельная правка тестов (не привлекается доп инженер (qa), для того, чтобы оценить/пофиксить тесты)
однозначный ответ о результатах тестов (не используются нестабильные/флакающие тесты)
благодаря правильному распределению по пирамиде, поддержка тестов становится минимальной, плюс их поддерживают все инженеры, а не только QA что сокращает время
весь процесс автоматизации непрерывен и встроен в CI сервиса (что упрощает поддержку и сокращает время реакции)
По поводу QA в разработке. Это часть процесса повышения инженерной культуры в команде. Благодаря ему, QA теперь полноценно знают, как разрабатывается продукт, они более качественно продумывают и задумываются об обеспечении качества процессов (в том числе и технической части).
С QA было снято много ручной активности (благодаря автоматизации и процессам T-shape) - их не дергают на каждую задачу, они не проверяют каждую задачу, меньше не нужной коммуникации. Поэтому у них появляется время для улучшения этих самых процессов обеспечения качества, для всей команды.
Разработка задач QA специалистами помогает также закрыть проблемы на этапах разработки, например в небольших командах и в случаях отпуска разрабов и др басфакторов. Мы будем уверены, что поставка останется предсказуемой и непрерывной.
Плюс при таком подходе (t-shape) формируется психологический фактор, что за инженером только прод! А не мифическая инстанция в виде тестеров) Что помогает каждому инженеру продумывать и следовать всем процессам обеспечения качества.
На счет цены вопроса.
Мы одобряем улучшение технических навыков у специалистов, рост инженерной культуры и проф скилов. Поэтому это может являться хорошим пруфом для роста QA! Поэтому в этом аспекте проблем не видим.
Разработчики, в принципе, могут и системной аналитикой самостоятельно заниматься.
У нас T-shape, а у вас?