Як переконати членів команди у існуванні "мандельбугу"

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

Нещодавно я виявив mandelbug збій додатка рішень іноді. Я міг відтворити його один раз і отримав слід стека, тому я відкрив звіт про помилку. Саму помилку легко виправити (невиконаний веб-виняток в одному з фонових потоків, що змушує CLR припиняти програму).

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

Будь-яка порада?

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

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

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

Отже, з ваших більш-менш уточнюючих коментарів я зрозумів це так:

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

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

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

EDIT: коли розробник все ж відмовляється додати цю зміну, найкращим варіантом є намагання змусити проблемний код працювати всередині ізольованого тестового ременя, де ви імітуєте мережеву помилку. Ефективна робота зі застарілим кодом описує безліч методів, як вирішити подібні проблеми. Наприклад, ви можете створити тестову версію бібліотеки, що включає лише проблемні модулі та функції, і створити навколо неї "макетне середовище", де ви зможете імітувати "мережевий виняток" в контрольованих умовах. На перший погляд це може здатися занадто великим зусиллям, але, маючи таке середовище, ви можете додати до нього багато додаткових тестів (і, мабуть, це матиме сенс, оскільки коли автор Lib відмовляється додати відсутні виняток в одному місці,

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

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

Адвокат диявола пропонує інший шлях.

Інший розробник однозначно заявив, що помилок там немає.

Чи можете ви придумати спосіб викреслити пекло від його нібито неіснуючої помилки та привести її до краху набагато частіше?

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

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

Наприклад, кілька місяців тому я виправив помилку, яка сталася лише тоді, коли користувач набрав швидше 96 слів за хвилину. Перш ніж я це виправляв, все, що я знав, - це те, що помилка траплялася «іноді». Мені ніколи не спадало б на думку написати тест для швидкого набору тексту. Однак після того, як я дізнався про першопричину, зробити тест на це було дрібницею.

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