«Это не баг, а несуществующий кейс»

Понравилась фраза в Твиттере у Вадима Макеева — «это не баг, а несуществующий кейс».

За прошедшие годы я вполне научился понимать, что не все баги нужно править, а эта фраза поможет в некоторых случаях быстро донести эту мысль до других. Правда, как это часто бывает с такими высказываниями, тут большое поле для трактовок. У меня есть понимание, что не все баги надо править, но так же я понимаю, что наткнувшись на «несуществующий кейс» нелишне узнать почему в этом случае программа ведёт себя неожиданно.

Например, если на какое-то сочетание входных параметров ваше веб-приложение тихо паникует в лог, лучше разобраться почему так происходит — и в существующих кейсах может вылезти та же ошибка, она ведь рождается в каком-то рабочем коде, а не просто аппендиксе для «несуществующих кейсов». Именно поэтому я люблю при тестировании поставить в URL что-нибудь странное.

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

Резюме. Моё мнение такое: не все баги надо править, но все — исследовать.

Комментарии 15

Михаил Иванов (m-ivanov.livejournal.com) № 1
По-моему, эта фраза сродни «программа хорошо документирована на языке C». Читай — отмазка. Что это за баги, которые не нужно править?
Евгений Степанищев (bolknote.ru) автор № 2
Баги, которые править не нужно, это (при условии, что они не создают брешей):

1) не являющиеся критичными (в условиях сжатых сроков)
2) проявляющихся в условиях, которые не достижимы в штатном режиме (например, через FireBug hidden-поле заполнили левыми данными)
3) не являющиеся таковыми («файл program.exe, который я скачал с вашего сайта, не запустился на моём „Маке“»)
silent № 3
Если баг не починили, значит он еще всплывет и найдет его обычный пользователь. Чинить надо все.
warmland.ru № 4
Например, баг проявляется в админке. Он не разрушителен. Имеет известный workaround. Затрагивает однократную процедуру конфигурирования системы. Новая система такого типа ставится раз в год. Будете чинить или займётесь чем-то более полезным?
Евгений Степанищев (bolknote.ru) автор № 8
Если баг не починили, значит он еще всплывет и найдет его обычный пользователь. Чинить надо все.

В t → ∞, конечно все.

Orcinus Orca (orcinus.ru) № 5
При сжатых сроках сдачи, можно игнорировать такие проблемы как разрушение дизайна если пользователь откорректировал хидден поля в передаваемой форме. Еще была фитча у Майл.ру, там чтобы не генерить лишний запрос при отображении сообщений, в GET передавалось кол-во писем. Можно было его откорректировать и в своем сеансе видеть любое кол-во писем. Это не критичная ошибка которая позволяет экономить массу запросов к БД.
Вадим Макеев № 6
Мне эту фразу выдал сотрудник Яндекса в блогах на Ярушке, когда я сказал, что у них лайт-почта на планшетниках разваливается в районе шапки и добавил, что я сам онлайн-почтой не пользуюсь. В этом случае это была явная отмазка, благо что вёрстка точно так же разваливалась при маленькой ширине и в десктопных браузерах.
stalkn № 10
http://ithappens.ru/story/840

#840: Закрепляющее + слабительное

Серьёзный космический проект. Интегрируется система дифференциальных уравнений движения спутника. С точки зрения программеров — примитивное консольное приложение, которое периодически выводит в левый верхний угол экрана время, в течение которого летает спутник, и его координаты. Все данные мы сверяем с аналогичной программой, созданной в другом институте — так сказать, проверяем друг друга на вшивость.

Всё бы хорошо, но время от времени спутник «прыгает назад» во времени часов на двенадцать. При этом в каждый момент времени он по нашим расчётам находится там, где и должен быть — вроде как ошибок нет.

Однако временные скачки напрягают, и после изучения кода я таки нахожу баг — даже и не баг, а глупую опечатку. Исправляю, запускаю прогноз движения… и спутник «улетает» со свехсветовой скоростью за пределы галактики!

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

С тех пор я помню: при отладке программер, как правило, наблюдает сложный результат интерференции нескольких багов и исправление одного из них не всегда меняет ситуацию в лучшую сторону.
Евгений Степанищев (bolknote.ru) автор № 11

http://mihschool-1-11a.ucoz.ru/publ/1-1-0-7

Ошибки допускают многократное вложение друг в друга.
Две одинаковые вложенные ошибки называются четной ошибкой и ошибкой не являются.
Свойство четности ошибок. Если написанная программа сработала правильно, то это значит, что во время ее работы выполнилось четное число ошибок или программист не понял задания.
Следствие. Чтобы получать правильные результаты, следует в каждой ветви программы предусмотреть четное число ошибок.
boltai-shaltai № 14
Комментарий для Евгения Степанищева:

У меня офигенный опыт. Смешно читать про «кейсы».

Могу рассказать детальнее, но не публично же.
Евгений Степанищев (bolknote.ru) автор № 15
Комментарий для boltai-shaltai:

Да и у меня офигенный опыт. Ничего смешного не вижу.