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

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

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

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

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

Ответы [ 23 ]

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

Если вы не воспроизвели ошибку, ваше «исправление» - не что иное, как предположение.

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

с макушки головы:

  • Вы можете случайно добавить новые ошибки с исправлениями
  • Вы не можете быть на 100% уверены, что исправление действительно исправляет ошибку без тестирования (за исключением, может быть, в самых простых случаях)
11 голосов
/ 15 февраля 2009

Я большой сторонник воспроизведения ошибок, если это экономически целесообразно (например, не копировать весь жесткий диск какого-либо пользователя на локальный компьютер просто для воспроизведения среды).

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

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

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

Характер ошибки также под вопросом:

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

  2. Можно ли воспроизвести дефект программно (например, с помощью сценариев Perl или Python)? Если это так, команда QA, вероятно, должна иметь автоматизированный контрольный пример, который покрывает его и может быстро использоваться для проверки.

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

Эти три принципа очень помогают управлять процессом контроля качества в моей команде по тестированию.

Как правило, в интересах разработчика самостоятельно воспроизвести дефект. Если это невозможно (например, нехватка аппаратных ресурсов), лучше всего будет работать напрямую с QA (или с тем, кто изначально пометил ошибку). Хотя некоторые дефекты достаточно очевидны (например, орфографическая ошибка в параметре меню), другие могут иметь более серьезные последствия, которые могут быть обнаружены разработчиком, который знает основное состояние приложения.

Также полезно, чтобы разработчики воспроизводили дефекты, чтобы подтвердить, что они действительно являются дефектами. Тестеры, хотя и необходимы (говоря как тестер программного обеспечения;)), часто не имеют глубоких знаний кода приложения и могут не иметь четкого понимания того, почему поведение не соответствует их ожиданиям (или спецификациям).

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

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

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

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

Основной принцип разработки, основанной на тестировании, заключается в том, что у вас есть тест, демонстрирующий некоторые функции.

В этом случае вы создаете тест, который демонстрирует ошибку. Тест не пройден.

Вы исправили ошибку. Тест проходит. Как и все остальные тесты. Вы на самом деле исправили ошибку, не создавая других проблем.

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

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

Если вы не репро, то вы

  • сэкономьте время / усилия сейчас, но
  • несут риск

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

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

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

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

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

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

  • возвращает исправление и проверяет, исправилась ли ошибка снова
  • возвращаем исправление и видим, исправлена ​​ли ошибка снова

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

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

РЕДАКТИРОВАТЬ: Я работал в месте, где владелец был очень расстроен из-за ошибок, которые, как утверждали, были исправлены, но не были. Это произошло потому, что хотя я (или другой разработчик) смог воспроизвести ошибку, я не воспроизвел ее точно так же, как ее создал тестер. Вы должны не только воспроизвести ошибку, но , вы должны убедиться, что воспроизводите ошибку точно так же, как тестер сделал .

(Но если вы хотите сначала попробовать самостоятельно, продолжайте; возможно, вы найдете еще одну ошибку! После этого попросите тестировщика продемонстрировать свое воспроизведение перед тем, как вы начнете работать над ошибкой.)

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

Вы спешите? Если так, то воспроизведите ошибки! Это создает методическое мышление, которое вам необходимо для предотвращения дальнейших проблем. Как еще вы могли бы обнаружить повторные ошибки? Воспроизведение ошибок привлечет внимание других:

Хороший менеджер : «Что ты делаешь?»

Хороший разработчик : «Мы снова получили эту ошибку. Я перестраиваю тестовую среду, чтобы мы могли воспроизвести ее».

Хороший менеджер : "WTF? Я думал, что Дейв сказал, что он исправил это? Эй, Дейв, ты не исправил эту ошибку? Почему мы снова тратим наше время на это?

Versus:

Менеджер задниц-шляп : «Что ты делаешь?»

Хороший разработчик : «Мы снова получили эту ошибку. Я перестраиваю тестовую среду, чтобы мы могли воспроизвести ее».

Ass-hat Manager : "Нет - у нас нет времени. Просто исправьте это и откатите. Вы ответили на электронное письмо о встрече? Мне нужно идти - мне нужно 10 с Стив. Хорошо. А, откинь это назад, а затем пошли это электронное письмо. "

Как директор, я приказываю всем моим командам "не торопиться с сегодняшним днем", чтобы понять это правильно, чтобы мы не встали в полночь.

...