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

14

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

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

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

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

ген б.
источник
Я нашел несколько предложений, которые могут оказаться полезными - Проверка кода в Agile Teams - часть II (найдена в результате очень быстрого поиска в Google - возможно, вы сможете найти больше).
Dukeling
1
Ваши тестеры работают над "освобожденными" задачами? Включает ли определение вашей команды «выпущенный» обзор кода и разрешение элемента действия? Или проверка кода происходит за пределами определения вашей команды?
Кент А.
1
У вашей тестовой команды нет автоматизированного набора регрессий?
Теластин
5
Как вы делаете «обзоры кода»? Является ли это длительным формальным процессом, когда рецензенты должны проработать полный контрольный список показателей качества (усилия: несколько человеко-часов)? Или любой другой член команды просматривает код и задает вопросы, если что-то не так (усилие: 10–30 минут для программиста и рецензента)? Почему вы делаете обзоры кода? Для обеспечения качества кода? Чтобы ловить ошибки? Распространять знания о системе между несколькими людьми? Ваш механизм проверки кода помогает в достижении этих целей, или это просто бюрократия, которую никто не хочет делать?
Амон
Мне нравятся все ответы, но позвольте мне добавить пункт, который я считаю важным. Вы спрашиваете, неверно ли вы интерпретируете Agile, но не говорите, какую методологию. Вы следуете за Scrum? Самое главное: у вас есть определение «Готово»? Я спрашиваю, потому что я нахожу это очень ... странным, что вы рассматриваете что-то «доставленное», прежде чем закончите работать над этим. Похоже, проверка кода - это нечто «дополнительное», которое вы делаете просто потому, что.
Лоренцо Дематте

Ответы:

8

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

Джон
источник
2
+1 В методологии Agile ежедневного выпуска не открывайте задачи заново. Создайте новое задание для решения найденных проблем и запланируйте его в соответствии с приоритетами вашей команды. Новые задачи = новое действие QA (что, вероятно, означает повторное выполнение тех же тестов). Если QA не нравится, есть много других профессий.
Кент А.
Это явно работает, но кажется неэффективным.
USR
7

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

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

Кевин Клайн
источник
5

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

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

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

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

Алан Шутко
источник
1

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

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

Низко летящий пеликан
источник
1

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

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

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

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

f1dave
источник