Як боротися з помилкою, яка, схоже, виправлена? [зачинено]

Я розробник веб-додатків для внутрішньої системи. Користувач повідомляє, що є помилка.

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

Як слід відповідати клієнтові та користувачеві?

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

Якщо він є, то ви можете дослідити помилку і переконатися, що в поточній версії її немає. Потім закрийте звіт про помилку з коментарем, що незв’язана зміна виправила його. Додайте регресійний тест, якщо потрібно.

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

• Вимкніть помилку, якщо не існує відтворюваного тесту?
• Як виділити важкі для відтворення помилки?
• Як найбільш ефективно налагоджувати код?
• Незрозумілі помилки?
• Що робити з помилками, які не дорікають?

Я припускаю, що ви справді зробили все, що могли, щоб відтворити помилку, але не можете.

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

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

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

У своєму трекері помилок обов'язково поясніть, які кроки ви пробували, так що якщо помилка повториться, людина, яка її обробляє, матиме певний досвід у тому, що робилося раніше.

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

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

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

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