Що робити з помилками, які не дорікають?

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

Тепер це все-таки помилки, я не хочу їх ігнорувати. Але без кроків докорів я якось застряг. Іноді є слід стека (хоча часто це не корисно, оскільки це компактний фреймворк і немає рядків). Але коли є такий, я можу взяти слід стека і розкрити код і почати здогадуватися, але це не призводить до перевірених "виправлень".

Що ви робите в таких сценаріях?

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

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

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

Однак, скільки часу потрібно у вас, щоб дійти до цієї точки, є дискусійним.

Деякі люди стверджують, що якщо це не відразу відтворюється, то його слід негайно закрити.

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

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

Ще кілька пропозицій:

1. Додайте журнал (а не лише кейлоггер:}) у свій код продукту. Помилки "Без репро" можуть бути флюсами, але це може бути пам'ять або пошкодження стану, що виникає лише в брудній системі, що використовується непередбачуваними способами (наприклад, як комп'ютер клієнтів). Реєстрація або відстеження інформації може допомогти вам зрозуміти, що могло статися не так, коли тестер виявив заклинання.

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

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

Я роблю QA у великому комерційному кодексі, цей дратівливий сценарій виходить занадто часто. Зазвичай це вказує на те, що на всіх платформах, які ми підтримуємо, немає необхідних процедур побудови бінарних файлів. Отже, якщо розробник створює власний код (який він повинен зробити для налагодження та виправлення), і не дотримується тієї самої збірки, продовжуючи букву, є ймовірність, що помилки, які залежать від системи, виявляться магічно зникли (або з'являться) . Звичайно, ці речі зазвичай закриваються "працює для мене" в базі даних про помилки, і якщо вони наступного разу запускаються, помилка може бути знову відкрита. Щоразу, коли я підозрюю, що помилка може залежати від системи, я намагаюся протестувати її на різних платформах і повідомляти, при яких умовах це відбувається. Часто проблема з пошкодженням пам’яті з’являється, якщо пошкоджені дані мають велику величину, щоб викликати збій. Деякі платформи (комбінації HW та OS) можуть вийти з ладу ближче до фактичного джерела корупції, і це може бути дуже цінним для бідного хлопця, який має його налагодити.

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

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

Існує два види помилок, які не відтворюються:

1) Ті, які тестер (або користувач) бачили один раз, але або не змогли або не намагалися відтворити.

У цих ситуаціях слід:

• Дуже коротко перевірте основний хід дій, які виявили дефект, щоб переконатися, що він не відтворюється.

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

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

• Якщо у вас все ще недостатньо, то потрібно пояснити користувачеві / тестувачу, що у вас недостатньо інформації. Ввічливо опишіть їм, як виглядатиме достатньо інформації та навіщо вона потрібна.

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

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

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

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

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

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

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

наклейте кейлоггер на робочу станцію цього тестера!

Ну, перше завдання - мати відтворювану тестову систему. Ваш тестер повинен мати чітко визначений процес - автоматичний, якщо це можливо.

Майте ці три умови:

• Те ж бінарне
• Ті ж кроки
• Та сама машина

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

Один із способів виявлення помилок управління пам'яттю - це запуск програми на декількох ОС з кількома компіляторами. Вальгринд також може допомогти.

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

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

Залежно від тяжкості помилки, ви можете вкласти певний час на неї або (краще) проігнорувати її, поки не будуть передбачені кроки повторної дії.