Як поводитися з помилками, які, на мою думку, я виправив, але я не зовсім впевнений

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

Якби я встановив " statusфіксований", а " solutionфіксований", це означало б щось повністю виправлене, чи не так?

Чи загальноприйнята практика встановлювати значення " statusфіксовано" та " solutionвідкривати", щоб зазначити тестерам, що "це, мабуть, виправлено, але для цього потрібно більше уваги"?

Редагувати: більшість (якщо не всі) помилки мають два властивості для статусу помилки, можливо, імена не однакові. До statusЯ маю в виду новий, призначений, фіксований, закритий, і т.д. , і solutionя маю в виду відкритий (новий), фіксований, нерозв'язною, що не відтвореним, дублювати, не помилка і т.д.

Чи загальноприйнята практика встановлювати статус фіксованим, а рішення відкривати, вказувати тестерам, що "це, мабуть, виправлено, але для цього потрібно більше уваги"?

Поширене чи ні, це все-таки правильно робити, і ви виклали, чому самі: як би там не було, це хороший підхід до

вкажіть тестерам, що "це, мабуть, виправлено, але йому потрібно приділити більше уваги"

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

_{... і якщо програма відслідковування помилок не дозволяє додавати коментарі до проблеми, її слід замінити на той, що робить. Можливість додавати роз'яснення у вільній формі є критично важливою особливістю, оскільки питання занадто сильно відрізняються, щоб вписатись у якусь попередньо визначену форму.}

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

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

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

Наприклад, скажімо, ви змінюєте програму, і тестер вкладає 1 годину на спробу відтворити помилку, а помилка не вискочить - вистачило однієї години? Або додатково тестувати марну трату часу, тому що помилка вже була виправлена?

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

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

Іноді єдині наявні у вас докази - це лише статистичні дані, наприклад, це відбувається один-два рази на місяць, але в іншому випадку, здавалося б, не пов'язане ні з чим. Це загалом найгірший тип помилок для діагностики та усунення, з якими я коли-небудь стикався, тому що ви не можете сказати, чи ваші виправлення впливають на певну ефективність. Останній з них, який мені довелося вирішити, закінчився статистичним виправленням: частота симптомів знизилася до 10%, з якої ми почали. Остаточного твору так і не було знайдено, а може і було, але ніхто не мав можливості сказати.

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