Проверка кода отстает от цикла доставки / тестирования

В нашем гибком процессе у нас есть 2-недельные спринты. Задачи выполняются ежедневно (ежедневные сборки), и группа тестирования завершает свое тестирование немедленно на следующий день или даже в тот же день.

У нас также есть проверки кода Dev, которые требуют некоторого времени (1-2 часа), поэтому они запланированы 3 раза в неделю: пн-пт-пт. Разработчики собираются вместе и предлагают, как улучшить / изменить код.

Наша проблема в том, что к тому моменту, когда элементы Action появляются после проверки кода, большинство задач уже протестировано. Тестеры не хотят повторно тестировать то, что уже прошло их тесты. Они не заботятся о внутренних изменениях разработчиков.

Неужели мы неправильно понимаем процесс Agile? Являются ли проверки кода несовместимыми с ежедневным циклом выпуска / тестирования? Мы не можем проводить проверки кода каждый день, так как они отнимают у всех время.

Тестеры не хотят повторного тестирования, все равно что сказать: «кодеры не хотят проводить рефакторинг». Это часть работы. Процесс можно переформулировать примерно так: задачи созданы. Код генерируется. Код проверен. Код пересматривается. Недостатки найдены в коде. Новые задачи создаются для устранения этих недостатков (например, код подвергается рефакторингу). Эти новые задачи требуют нового тестирования.

Если вы собираетесь пересмотреть код в какой-то момент, обзор не дороже. И, кажется, у вас дорогой процесс тестирования, поэтому вы не хотите тестировать дважды. Поэтому дешевле проверить код перед тестированием. Просмотр кода после тестирования не ускоряет работу. Это замедляет работу и заставляет вас писать плохо написанный, но успешно протестированный код. Со временем весь этот непроверенный код сделает работу все медленнее и медленнее. Тогда более эффективный конкурент поставляет лучший продукт с меньшими затратами, и игра окончена.

Кроме того, автоматизируйте тестирование. Ручное тестирование это так 1970.

Если вам трудно добиться, чтобы проверки кода происходили в то время, которое у вас есть до QA, вам следует подумать о том, чтобы сделать проверки кода более легкими, как обсуждается в Code Review в Agile Teams, часть II , которую опубликовал @Dukeling.

Я обнаружил, что даже самая простая вещь, которую можно было бы назвать проверкой кода, давала преимущества: прежде чем фиксировать код (или выдвигать DVCS), вызовите еще одного разработчика и проведите их через все изменения. Это может занять пять или десять минут. Цель этого обзора кода: «Имеет ли это смысл для другого разработчика?» Цель состояла не в том, чтобы придираться к реализации проекта или полностью соответствовать личным представлениям рецензента о том, как это должно было быть написано. Это дало следующие преимущества:

• Улучшено общее знание того, как работает код
• Попадание в замешательство или потенциально ошибочный код, потому что объяснения кода было достаточно, чтобы автор переосмыслил
• Помогал постепенно развивать командные идиомы и стиль, потому что это облегчало объяснение вещей
• Очень мало ворча от команды

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

Одним из решений этой проблемы является быстрое рассмотрение кода другим партнером после завершения пользовательской истории, чтобы не было никаких базовых / очевидных ошибок в коде.

Но это должно произойти до цикла испытаний. Тогда будет меньше изменений кода после теста, когда вы сделаете большую проверку со всей командой.

Судя по всему, тестеры не хотят повторного тестирования, потому что тестирование - это болезненный / дорогой процесс.

Автоматизация тестирования как разработчиками, так и тестерами является огромным бонусом для команд, стремящихся работать гибко. Чем дешевле, проще и воспроизводимее ваши тесты, тем больше вы можете их выполнить - и тем меньше вы будете сопротивляться изменению чего-либо.

Сделал быстрый рефакторинг на основе отзывов разработчиков? Нажмите большую красную кнопку, которая запускает вашу программу регрессии / курения, и сделайте короткое ручное руководство, чтобы проверить наличие каких-либо проблем со зрением, которые могли возникнуть. Легко!

Как только вы окажетесь в таком месте, повторное тестирование не будет рутиной - это будет вторая натура.