Огляд коду відстає від циклу доставки / тестування

14

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

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

Наша проблема полягає в тому, що до моменту появи елементів дії після огляду коду більшість завдань вже перевірені. Тестери не хочуть повторно перевіряти те, що вже пройшли свої тести. Їм не байдуже внутрішні зміни розробників.

Ми нерозуміємо процес Agile? Чи огляди коду несумісні з щоденним циклом випуску / тестування? Ми не можемо проводити огляд коду щодня, оскільки вони займають час кожного.

— ген b.
джерело

Я знайшов декілька пропозицій, які можуть бути корисними - Перегляд коду в Agile Teams - частина II (знайдено в результаті дуже швидкого пошуку в Google - можливо, ви зможете знайти більше).

— Герцогство

1

Чи працюють ваші тестери над "звільненими" завданнями? Чи включає визначення вашої команди "звільнене" перегляд коду та дозвіл пункту дії? Або перегляд коду відбувається за межами визначення вашої команди?

— Кент А.

1

Чи не має ваша тестова група автоматизованого набору регресії?

— Теластин

5

Як ви робите «огляди коду»? Це тривалий формальний процес, коли рецензенти повинні опрацювати цілий контрольний список показників якості (зусилля: кілька людей-годин)? Або це просто будь-який інший член команди, який переглядає код і запитує, чи щось здається (зусилля: 10–30 хвилин для кодера та рецензента)? Чому ви робите огляди коду? Для забезпечення якості коду? Ловити помилок? Поширити знання про систему між кількома особами? Чи допомагає ваш механізм перегляду коду досягти цих цілей, чи це просто бюрократія, якої ніхто не хоче робити?

— амон

Мені подобаються всі відповіді, але дозвольте додати пункт, який я вважаю важливим. Ви запитуєте, чи неправильно трактуєте Agile, але ви не кажете, яка методологія. Ви стежите за Scrum? Найголовніше: чи є у вас визначення "Готово"? Я прошу, тому що мені здається дуже дивно, що ви розглядаєте щось "доставлене", перш ніж закінчити фактично працювати над цим. Здається, що перегляд коду - це щось «зайве», яке ви робите саме тому.

— Лоренцо Дематте

8

Тестери не хочуть повторно випробовувати щось на зразок того, що говорять "кодери не хочуть робити рефактор". Її частина роботи. Процес можна відновити приблизно так: Завдання створюються. Код генерується. Код перевіряється. Код переглядають. Недосконалість виявляється в коді. Для усунення цих недосконалостей створюються нові завдання (наприклад, код є відновленим). Ці нові завдання потребують нового тестування.

— Джон
джерело

2

+1 У методології Agile щоденного випуску не відкривайте завдання. Створіть нове завдання для вирішення знайдених проблем та сплануйте його відповідно до пріоритетів вашої команди. Нові завдання = нова QA-дія (що, ймовірно, означає повторне проведення тих же тестів). Якщо QA не подобається, є багато інших кар'єр.

— Кент А.

Це однозначно працює, але здається неефективним.

— usr

7

Якщо ви збираєтеся переглянути якийсь код в якийсь момент, зробити це огляд не дорожче рано. І, здається, у вас дорогий процес тестування, тому ви не хочете тестувати двічі. Тому дешевше переглянути код перед тестуванням. Перегляд коду після тестування не прискорить роботу. Це робить його повільніше і спокушає вас доставити погано написаний, але успішно перевірений код. З часом весь цей неперевірений код зробить роботу повільнішою та повільнішою. Тоді більш ефективний конкурент доставляє кращий товар за меншими витратами, і на ньому гра закінчена.

Також автоматизуйте тестування. Ручне тестування - це 1970 рік.

— Кевін Клайн
джерело

5

Якщо вам важко зрозуміти, що відгуки про коди трапляються за час, який ви маєте до QA, вам слід подумати про те, щоб зробити огляди коду більш легкими, як обговорення коду в Agile Teams, II частина , яку опублікував @Dukeling.

Я виявив, що навіть найпростіша річ, яку можна назвати переглядом коду, дає переваги: перед тим, як ввести код (або натиснути на DVCS), зателефонуйте іншому розробнику та перегляньте їх через вашу зміну. Це може зайняти п'ять-десять хвилин. Мета цього огляду коду - "Чи має сенс інший розробник?" Мета не полягала в тому, щоб вибирати реалізацію дизайну або повністю відповідати особистим уявленням рецензента про те, як це повинно бути написано. Це дало ці переваги:

Вдосконалено спільні знання про те, як працював код
Натрапив на заплутаний чи потенційно помилковий код, оскільки акт пояснення коду був достатній, щоб змусити автора переосмислити речі
Допомагав поступово розвивати командні ідіоми та стиль, адже це полегшувало пояснення речей
Дуже мало бурмотить від команди

Більш глибокі відгуки про код абсолютно працюють краще, щоб знайти проблеми. Але ви повинні вміти їх робити і діяти на них, щоб отримати цінність. Легкий процес, який ви можете робити весь час, може бути кориснішим, ніж процес важкої ваги, який постійно відкладається, або просто додає речі до відставання.

— Алан Шутко
джерело

1

Одне з варіантів вирішення цієї проблеми - зробити швидкий огляд коду іншим одноранговим, коли історія користувача закінчена, так що в коді не буде основних / очевидних помилок.

Але це має відбутися до циклу тестування. Тоді буде менше змін коду після тесту, коли ви робите більші огляди з усією командою разом.

— Пелікан низького польоту
джерело

1

Із звуків цього тестери не хочуть повторно перевіряти, оскільки тестування - це болісний / дорогий процес.

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

Зробили швидкий рефактор на основі девайсів зворотного зв’язку? Натисніть велику червону кнопку, яка виконує ваш регресійний / димовий набір, і ще раз зробіть швидкий посібник, щоб перевірити, чи не виникли проблеми із зором. Легко!

Коли ви опинитесь у такому місці, повторне тестування не стане справою - це буде другою природою.

— f1dave
джерело