Як закрити помилку, яка вже не актуальна

21

Зараз я в середній команді веб-розробників. Ми використовуємо jira для відстеження помилок.

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

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

issue-tracking jira

— Бенджамін Грюенбаум
джерело

8

Занадто локалізовано;)

— yannis

4

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

— jk.

6

@jk. Хе, я мав на увазі "занадто локалізований" як пропозиція / відповідь на питання, не те, що саме питання є "занадто локалізованим". Якби я подумав останнє, я би його просто закрив.

— янніс

2

@YannisRizos doh! можливо, це мала бути тоді відповідь;)

— jk.

6

@jk. Я думаю, що друге питання є цікавішим (це навіть має значення?), Але я зараз не встигаю відповісти на це (і я не дуже впевнений, що відповідь, що формується в моїй голові, хороший). Що стосується першого питання, якщо ця нитка перетвориться на "слово / словосполучення", вона може закритися як "неконструктивна". Тож, відповідачі, не ігноруйте друге питання, будь ласка, це тематичне та цікаве питання.

— янніс

26

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

Ця ситуація стає набагато менш заплутаною, якщо дивитися на неї з точки зору тестера. Якщо у вашій команді немає тестера, уявіть її (а ще краще, найміть один ^{1 , 2 , 3} ).

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

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

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

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

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

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

Один з індивідуальних JIRA, з яким я працював у минулому проекті, мав резолюцію "Fixed By Design", щоб повідомити про досить глибокі зміни, що мають чимало наслідків, деякі - навмисні, а інші - ні. У такому випадку, як ви описуєте, це може бути розглянуто замість простого "Виправленого", оскільки він натякає на те, що він читає квитки, що це більше побічний ефект, а не навмисна зміна коду.

— гнат
джерело

2

Виправлене дизайном означало б для мене повну протилежність цьому. На мій погляд, задум означає «навмисне» (це протилежне «помилково»).

— TRiG

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

1

@TRiG добре, тому я зазначив, що краще пояснити точні деталі в коментарях. Fixed By Design трохи ширший; У проекті, який я бачив, він використовувався для спілкування досить глибоких змін, що мають чимало наслідків, деякі навмисні, а інші - не охоплюючи подібні випадки. Зауважте також, ні текст запитання, ні моя відповідь не означають "помилку виправити" (яка помилка?) - тут "ненавмисне" набагато краще підходить

— gnat

1

Усі відповіді хороші, але ця, здається, це підкреслює. Дякую всім.

— Бенджамін Груенбаум

6

Як щодо "Виправлено переробленням"?

— пінгват

47

Ми вирішуємо такі питання, як "застарілі". Це не роздільна здатність за замовчуванням у JIRA, але її досить просто додати.

— Кріс
джерело

+1, якщо ви не можете додати його, принаймні вибирайте, як це не помилку, і коментуйте чому

— tgkprog

9

JIRA (і я впевнений, що інші трекери помилок) дозволяє вказувати власні рішення, тому ви повинні мати змогу встановити розділ "Перебіг подіями" або "Іррелавант" або подібне, щоб ви могли висловити закриття як ви хочете

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

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

— jk.
джерело

1

"Над захопленими подіями" занадто довгий (імхо), я б хотів пройти одним словом (нерелевантним / застарілим) лише тому, що його простіше шукати і займає менше місця (у звітах тощо). Один раз, коли знали кількість наших застарілих помилок, було корисно, коли вони надходили масово, і це вказувало на проблему зв'язку. Наші тестери не були в курсі того, над чим працювали наші розробники, вони пропустили пам’ятку про те, що все буде невдало протягом тижня або близько того і видають (марний) шум. Отже, озираючись на наш замок. помилки допомогли нам знайти та виправити дірку в наших комунікаційних процесах.

— янніс

3

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

— jk.

3

@YannisRizos: виправлення мета-помилок за допомогою помилок. Як класно це!

— Йорг W Міттаг

@YannisRizos пошук не є великою проблемою, оскільки дійсні рішення вибираються зі спадного списку в будь-якому випадку (в JIRA)

— jk.

2

@Yannis. Я втратив би сон через це: наздогнати має бути одне слово.

— TRiG

5

Ми використовуємо FogBugz, але я впевнений, що те саме (або подібне) стосується і тут:

Ми просто використовуємо "Вирішено (виправлено)" і коментуємо в резолюції редагування щось на кшталт "Виправлено випадком 12345".

FogBugz відповідає "case \ d +" і пов'язує їх разом у відповідних випадках, але якщо Джира цього не зробить, просто додати посилання.

Це IMO краще, ніж варіант "Занадто локалізований", оскільки він був фактичною помилкою, і краще, ніж просто "Застарілий", оскільки він був виправлений, таку функцію не просто було видалено.

— Ізката
джерело

3

Виправлено за допомогою тверезості та повторної перевірки <- правдива історія.

— янніс

1

Джира також дозволяє такий підхід. Просто вкажіть номер питання в коментарях до вирішення, і Джира перетворить його на гіперпосилання.

— Мар'ян Венема