Должны ли мы всегда воспроизводить ошибки, чтобы проверить исправления? - PullRequest
23 голосов
/ 15 февраля 2009

Время от времени мы получаем ошибки в работе, которые можно исправить, например, путем изменения конфигурации, отключения некоторой части логики и т. Д.

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

Мой менеджер считает, что это пустая трата времени, так как решение работает, поэтому нет необходимости воспроизводить локально.

Итак: Должны ли мы попытаться воспроизвести локально, чтобы проверить исправления? Любые указания о том, как продать этот пункт моему менеджеру, если вы согласны со мной?

Ответы [ 23 ]

3 голосов
/ 15 февраля 2009

Вы должны всегда TRY . Вам необходимо определить, является ли это ошибкой, ошибкой или дефектом. Как вы можете исправить или смягчить проблему, не понимая ее?

Как это будет разрешено для набора записей или тестов? Является ли соответствующий статус
- «Исправлено», «Открыть», «Невозможно воспроизвести», «Не исправит», «Функция»?

Если вы не можете воспроизвести его, то решение все равно должно быть принято, чтобы позволить ему перейти в / dev / null и попросить его вернуться и укусить вас.

2 голосов
/ 15 февраля 2009

Я думаю, что ответ на этот вопрос зависит от того, как вы тестируете свои ошибки.

  • Используете ли вы инструмент автоматического тестирования (например, фреймворки xUnit, Fit / Fitnesse и т. Д.)?
  • Используете ли вы автоматизированный процесс сборки?
  • Этот автоматизированный процесс сборки вызывает тесты и записывает результаты?

Если ответ на вышеупомянутые вопросы не будет положительным по всем направлениям, то включение проверок для проверки исправления ошибок будет утомительным и болезненным. Также будет трудно убедить менеджера применить время для включения этих проверок, потому что они всегда могут сказать: «Ну, у нас недостаточно людских ресурсов для этого» * ​​1011 *

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

Для моего проекта мы используем subversion для контроля версий, Jira для управления активностями, Hudson для сборок, Fitnesse и MSTest для тестирования. Все они связаны друг с другом с помощью непрерывной интеграции. Fitnesse проводит приемочные тесты и MSTest модульное тестирование, и они запускаются автоматически каждый раз, когда выполняется сборка, чтобы дать нам количественный показатель того, насколько «хорош» сборка.

2 голосов
/ 15 февраля 2009

Самая важная причина для того, чтобы воспроизвести ошибку локально, это убедиться, что вы ничего не привинтили во время ее исправления. Если исправление - это просто конфигурация или что-то, что не требует перекомпиляции, этот аргумент является менее мощным, так как все, что было скомпилировано, должно быть уже протестировано.

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

2 голосов
/ 15 февраля 2009

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

В конце концов, вы не можете быть уверены, что что-то является проблемой, пока не сможете воспроизвести это. До тех пор это просто гипотеза (даже если она хорошо информирована, она все еще остается догадкой).

Теперь, проводите ли вы юнит-тестирование или нет, я думаю, что это не имеет отношения к этому обсуждению, поскольку воспроизводимость - это просто вопрос, нашли ли вы ошибку ?. Модульный тест не поможет вам, если вы проверяете не то, работаете над некоторыми неверными предположениями или просто неправильно поняли (возможно, расплывчатый) отчет об ошибке о том, что на самом деле происходит.

Вот почему вы воспроизводите проблему.

1 голос
/ 06 мая 2013

Если вы не можете воспроизвести ошибку, вы не можете их исправить.

  • Изменение конфигурации, отключение некоторой части логики и т. Д. На производстве является временным решением.

  • Мы должны убедиться, что продукт надежен и отвечает требованиям клиентов, проводя локальное тестирование, кросс-устройства (для мобильных устройств, планшетов и т. Д.) И кросс-платформенное тестирование (Firefox, Chrome, Internet Explorer). Важная роль здесь.

  • Необходимо проверить, воспроизводится ли проблема в первую очередь локально, чтобы гарантировать качество продукта, потому что, если клиент обнаружит ту же проблему, это будет проблемой:)

  • Для обеспечения надежного и безошибочного понимания продукта и воспроизведения проблемы наиболее важны.

  • Как вы уже упоминали, ошибки исправляются (то есть не воспроизводятся) путем изменения конфигурации, отключения некоторой части логики и тому подобного. Но если у клиента та же конфигурация, которую вы в настоящее время изменяете, то это на самом деле будет большой проблемой, поэтому кросс-устройство (для мобильных устройств, планшетов и т. Д.) И кросс-платформенное (Firefox, Chrome, Internet Explorer) тестирование очень важно.

1 голос
/ 28 ноября 2009

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

Я особенно согласен с частью о разработчиках и QA, включая проверки. Это часть того, что японцы называют Jidoka (что означает «автоматизация с человеческим прикосновением»):

[...] Автономизация предотвращает производство бракованной продукции, устраняет перепроизводство и фокусирует внимание на понимание проблемы и обеспечение того, чтобы оно никогда не повторялось. Это это процесс контроля качества, который применяется следующие четыре принципа:

  1. Обнаружение неисправности.
  2. Stop.
  3. Исправить или исправить немедленное состояние.
  4. Расследуйте основную причину и установите контрмеры.

Существует контрмера для предотвращения повторения. Вот как вы создаете Poka-Yoke - защищенный от ошибок - процесс (и процесс, который позволяет возникать дефектам, является дефектным процессом). Хорошие менеджеры должны получить это.

1 голос
/ 15 февраля 2009

В большинстве случаев вы не можете знать, что ошибка, которую вы воспроизвели, совпадает с ошибкой, которую испытывает ваш клиент. Из-за этого воспроизведение не гарантирует, что проблема действительно решена.

Например, у клиентов возникла ошибка связи с проектом, над которым я работал. Мы искали код, чтобы исправить возможные ошибки. Одна ошибка включала ошибку ASIC в микропроцессоре PIC, а ошибки чипа предоставили обходной путь, который мы реализовали. Затем один из моих коллег прошел крайние меры, чтобы воспроизвести ошибку, чтобы он мог утверждать, что проблема нашего клиента, вероятно, была устранена.

Не было.

В конце мы добавили много защитного кода, и клиент больше никогда не сталкивался с проблемой. Мы не уверены, какое именно исправление решило проблему, и было бы замечательно узнать и воспроизвести проблему, с которой сталкивались наши клиенты, но в конце концов все это не имеет значения. Все, что имеет значение, это программное обеспечение работает.

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

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

1 голос
/ 15 февраля 2009

Несмотря на то, что модульное тестирование - это решение, и вам не нужно воспроизводить ошибку, если вы ее используете, звучит хорошо, но я не думаю, что она работает в реальном мире. Тот факт, что они не воспроизвели ошибку на сайте, означает, что воспроизведение, вероятно, не тривиально. Это, вероятно, означает, что источник сложен. Если бы проблему было тривиально представить в модульном тесте, этот модульный тест был бы воспроизведением ошибки. Если они не воспроизвели его, они, вероятно, не могут написать для него простой модульный тест.

Если вы не воспроизвели ошибку, вы по-настоящему ее не понимаете. Возможно, вы обнаружили ошибку в системе, но это не гарантирует, что вы обнаружили ошибку , которую видел клиент.

Если вы не можете воспроизвести ошибку, вы не можете быть уверены, что она действительно исправлена. Вы можете лечить только симптом проблемы, а не основную проблему. У клиента может быть другой вектор для той же основной проблемы, и его проблема не будет исправлена.

1 голос
/ 15 февраля 2009

да, когда это возможно / возможно; см. Регрессионное тестирование

0 голосов
/ 13 мая 2013
  • Поскольку ошибка уже находится в работе, это означает, что что-то могло пропустить во время тестирования, и это тоже по ошибке.
  • Через некоторое время, когда тестировщик / QA обнаружит ошибку или если клиент сообщит об этой ошибке, то со стороны разработчика будут сделаны некоторые исправления.
  • После исправления этих ошибок локально их следует проверить, если они воспроизводимы или не основаны на сценарии тестирования и тестовом покрытии, чтобы в будущем их больше не было в производстве, и клиент никогда не столкнется с ошибками или проблемами.
...