«Это не баг, а несуществующий кейс»
Понравилась фраза в Твиттере у Вадима Макеева — «это не баг, а несуществующий кейс».
За прошедшие годы я вполне научился понимать, что не все баги нужно править, а эта фраза поможет в некоторых случаях быстро донести эту мысль до других. Правда, как это часто бывает с такими высказываниями, тут большое поле для трактовок. У меня есть понимание, что не все баги надо править, но так же я понимаю, что наткнувшись на «несуществующий кейс» нелишне узнать почему в этом случае программа ведёт себя неожиданно.
Например, если на какое-то сочетание входных параметров ваше веб-приложение тихо паникует в лог, лучше разобраться почему так происходит — и в существующих кейсах может вылезти та же ошибка, она ведь рождается в каком-то рабочем коде, а не просто аппендиксе для «несуществующих кейсов». Именно поэтому я люблю при тестировании поставить в URL что-нибудь странное.
Иногда при попытке разобраться получаешь неожиданный опыт, который пригодится в будущем. Какой-то внешний вызов или конструкция языка ведут себя не так как вы ожидали, к примеру. Да и нелишне убедиться, что этот несуществующий кейс не разрушит данные, ведь если тестировщик на него как-то наткнулся, то не факт, что какой-то пользователь не тыкнет туда же случайно.
Резюме. Моё мнение такое: не все баги надо править, но все — исследовать.
По-моему, эта фраза сродни «программа хорошо документирована на языке C». Читай — отмазка. Что это за баги, которые не нужно править?
Комментарий для m-ivanov.livejournal.com:
Баги, которые править не нужно, это (при условии, что они не создают брешей):
1) не являющиеся критичными (в условиях сжатых сроков)
2) проявляющихся в условиях, которые не достижимы в штатном режиме (например, через FireBug hidden-поле заполнили левыми данными)
3) не являющиеся таковыми («файл program.exe, который я скачал с вашего сайта, не запустился на моём „Маке“»)
Если баг не починили, значит он еще всплывет и найдет его обычный пользователь. Чинить надо все.
Комментарий для silent:
Например, баг проявляется в админке. Он не разрушителен. Имеет известный workaround. Затрагивает однократную процедуру конфигурирования системы. Новая система такого типа ставится раз в год. Будете чинить или займётесь чем-то более полезным?
При сжатых сроках сдачи, можно игнорировать такие проблемы как разрушение дизайна если пользователь откорректировал хидден поля в передаваемой форме. Еще была фитча у Майл.ру, там чтобы не генерить лишний запрос при отображении сообщений, в GET передавалось кол-во писем. Можно было его откорректировать и в своем сеансе видеть любое кол-во писем. Это не критичная ошибка которая позволяет экономить массу запросов к БД.
Мне эту фразу выдал сотрудник Яндекса в блогах на Ярушке, когда я сказал, что у них лайт-почта на планшетниках разваливается в районе шапки и добавил, что я сам онлайн-почтой не пользуюсь. В этом случае это была явная отмазка, благо что вёрстка точно так же разваливалась при маленькой ширине и в десктопных браузерах.
Комментарий для Вадим Макеев:
Ага, нашёл, спасибо!
Комментарий для silent:
В t → ∞, конечно все.
не починённые баги это ерунда. вот самопочинившиеся часто гораздо хуже.
http://ithappens.ru/story/840
#840: Закрепляющее + слабительное
Серьёзный космический проект. Интегрируется система дифференциальных уравнений движения спутника. С точки зрения программеров — примитивное консольное приложение, которое периодически выводит в левый верхний угол экрана время, в течение которого летает спутник, и его координаты. Все данные мы сверяем с аналогичной программой, созданной в другом институте — так сказать, проверяем друг друга на вшивость.
Всё бы хорошо, но время от времени спутник «прыгает назад» во времени часов на двенадцать. При этом в каждый момент времени он по нашим расчётам находится там, где и должен быть — вроде как ошибок нет.
Однако временные скачки напрягают, и после изучения кода я таки нахожу баг — даже и не баг, а глупую опечатку. Исправляю, запускаю прогноз движения... и спутник «улетает» со свехсветовой скоростью за пределы галактики!
Восстанавливать старый код смысла нет. Продолжаю поиски и через час нахожу второй баг, который полностью компенсирует влияние первого. Между двумя ошибками и стоял оператор вывода информации на экран.
С тех пор я помню: при отладке программер, как правило, наблюдает сложный результат интерференции нескольких багов и исправление одного из них не всегда меняет ситуацию в лучшую сторону.
Комментарий для stalkn:
http://mihschool-1-11a.ucoz.ru/publ/1-1-0-7
Сотри, прошу, то что вверху ))
Комментарий для boltai-shaltai:
Стёр :)
Комментарий для Евгения Степанищева:
У меня офигенный опыт. Смешно читать про «кейсы».
Могу рассказать детальнее, но не публично же.
Комментарий для boltai-shaltai:
Да и у меня офигенный опыт. Ничего смешного не вижу.