Хто видаляє копії квитків на помилки?

9

Один з моїх товаришів по команді та я просто схопив окремі квитки на помилки, присвоїв їх окремо собі, але квитки були дублікатами!

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

— micahhoover
джерело

7

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

— Ден Пішельман

Вам, можливо, варто більше спілкуватися зі своїми товаришами по команді? Зазвичай ми говоримо колегам по тому ж проекту "Я закінчив це, збираюся зробити це зараз"

— NeeL

11

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

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

— Карл Білефельдт
джерело

3

Надішліть зміни коду під одним квитком, а потім вирішіть інший квиток із зауваженням, що "це дублікат, код знаходиться під помилкою # xxx".

Це відбувається постійно.

— Лоуренс Айелло
джерело

2

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

— JasonB
джерело

2

В ідеалі розробники не діятимуть на звітах про помилки до того, як вони дістануться до стадії "Triaged", де підтверджено наявність помилки, а не дубліката, та додається тестовий випадок чи інструкції щодо відтворення.

— Саймон Ріхтер

0

Дивіться також і позитивну сторону: Якщо одну і ту ж помилку було виявлено двічі самостійно, то її відтворення має бути легше. І розробниками, і замовниками :-( так що вищий пріоритет може бути виправлений.

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

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

— gnasher729
джерело