Comments 32
Как обосновать? «Да вы что, если если пользователь ТАКОЕ увидит, то он сразу обидится и уйдет.» Стоп. Включаем мозг. Это дебаг-панель. Она для тестировщиков и разработчиков, помощник в тестировании[2]. Пользователь ее НИКОГДА не увидит. А если увидит, то ВОТ ЭТО уже будет баг, причем критичный!
Само наличие такой некрасивости, пусть даже и в дебаг-панели, говорит об отсутствии чувства прекрасного (или понимания, как его быстро и качественно переводить в код) у того, кто ее создавал. Отличный повод ткнуть носом ответственного, чтобы потом это не пролезло по неряшливой привычке в какой-нибудь production-интерфейс. Т.е. все-таки (из-за риска сделать что-то по аналогии, типа «так сошло и еще раз сойдет») баг, но не критичный.
Это если вам нужны в баг-трекере баги, которые никто никогда не будет исправлять :)
Хотя, возможно, руки когда-нибудь и дойдут. У нас был такой мееееелкий бажик, даже не так страшно выглядет, табличка просто немного криво сужалась (но ее редко сужали и вообще она не на главном экране). А чтобы переделать, надо было кучу всего отрефакторить. Проверять 2 минуты, делать 2+ дня. Кстати, сделали в итоге, когда тестировщики перегружены были и большую задачу проверить бы не смогли.
Хотя, возможно, руки когда-нибудь и дойдут. У нас был такой мееееелкий бажик, даже не так страшно выглядет, табличка просто немного криво сужалась (но ее редко сужали и вообще она не на главном экране). А чтобы переделать, надо было кучу всего отрефакторить. Проверять 2 минуты, делать 2+ дня. Кстати, сделали в итоге, когда тестировщики перегружены были и большую задачу проверить бы не смогли.
Наличие такой некрасивости говорит о том, что люди не тратят ресурсы (читай — деньги) на функционал, который не зарабатывает деньги для бизнеса. И это отлично! Я вот совершенно не хочу, чтобы тулзы для разработки/тестирования обрастали ненужными свистоперделками за счет бюджета разработки. Ни как заказчик, ни как руководитель, ни как тестировщик.
Отличная статья, спасибо!
О да, каждый свой баг начинающий тестировщик считает Важным и/или Критичным. И изначально это даже поддерживается, чтоб мотивацию не терял. Потом уже грузят «экономь время разработчика», «оцени эффект на бизнес».
P.S. example.com не возвращает ошибку 500 (зато возвращает 404 на favicon, и то в консоли).
P.S. example.com не возвращает ошибку 500 (зато возвращает 404 на favicon, и то в консоли).
Если бы у меня был выбор между двумя поставщиками, один из которых исправляет ошибки, когда они уже болят у заказчика, а другой в поле ввода email принимал бы все, что положено по RFC, вместо того, чтобы считать сколько реально почтовых адресов в емейл.рф существует. Ох уж эти новомодные спринты с агайлами, как же уже забодали тяп-ляп и в продакшн, допилим в следующем спринте.
Так а какой выбор вы бы сделали? :) Про RFC есть хорошая статья — https://habrahabr.ru/post/224623/
Если бы выбор был, то я бы выбрал тех, кто пишет основательно, а не тяпляпает заплатки на заплатки по use кейсам. Но таких к сожалению все меньше и меньше. А потому, в рекламке на сайте будет красивая картинка про поддержку того и сего, а на самом деле оно будет работать наполовину и не всегда. А мне еще и придется месяцами доказывать, что это не платная доработка, а кто-то врет в рекламах, технических документациях и спецификациях заявляя поддержку того, чего на самом деле нет.
А приведенная вами статья, как минимум спорная. Хотя я очень хотел бы высказаться покрепче.
А приведенная вами статья, как минимум спорная. Хотя я очень хотел бы высказаться покрепче.
Захватывающе, интересно и очень по делу! Автор- пиши ЕЗЧО!
— Я пытаюсь зарегистрироваться с емейлом.рф и не могу. Это баг!(отчаянно пиная разработчика ногами) Потому. Что. Ты. Скотина. Недоученная. Нарушаешь
— Почему?
RFC 5321, глава 2.3.11. Это не твоё собачье дело — как именно система получателя интерпретирует локальную часть адреса!
Так если бы локальную. Про неё в описании бага ничего не сказано.
Тут похоже разработчик ожидал, что доменное имя строго на английском, и адрес @емейл.рф считает невалидным.
Тут похоже разработчик ожидал, что доменное имя строго на английском, и адрес @емейл.рф считает невалидным.
Нууууу, если так с разработчиками общаться, то быть войне)
Такая формулировка — это не просто «зайчики обиделись», а «боевые зайцы в ярости».
Между прочим, если вы прочитаете повнимательнее раздел про домены (https://tools.ietf.org/html/rfc5321#section-2.3.5), там есть ограничение на то, что символы должны быть из ASCII. Т.е. никаких кириллических символов.
А Вы правда-правда не в курсе, как кириллические домены работают? Например, что
.рф — это на самом деле .xn--p1ai?Вы мне пуникод не приплетайте, пользователь вам не в пуникоде адрес вводит. Соответственно, корректный с точки зрения RFC 5321 валидатор должен такие строки заворачивать. Просто если вы уж даете ссылки на стандарты, давайте ссылки на правильные, в данном случае https://tools.ietf.org/html/rfc6531#section-3.2
пользователь вам не в пуникоде адрес вводит
Совершенно верно. Стопитцот раз уже говорили — "единственная корректная валидация для емейлов — убедиться, что в строке встречается @. После чего посылаете тестовый емейл на этот адрес, и получаете от пользователя подтверждение получения (в виде клика на URL); всё остальное — от лукавого." Я не зря ссылку давал.
Однажды я зашла в баг-трекер и увидела такой баг от студента: «Мы вводим имя Шарипат, оно определяется как мужское. А должно — как женское!». Почему должно как женское? Я смотрю на это имя — ну Шарипат и Шарипат, выглядит как мужское. Я спрашиваю:
— Почему ты так решил? Почему женское?
— Да потому, что у меня жену так зовут!
Это ещё что! Имя Асет — в одних странах женское, а в других — мужское!
Спасибо за статью, будет обязательно к прочтению.
Милейшие картинки)
Милейшие картинки)
Студент нашел опечатку в оферте пользователя. Поставил баг с критикал-приоритетом.
Интересно, а если в оферте написано что пользователю предоставляется скидка в 200% на все услуги, это уже критикал приоритет или еще нет? Просто этот пример прекрасно попадает под ваше же описание как делать не надо — студента обвинили, а доказательств не привели.
Sign up to leave a comment.
Паттерны и антипаттерны обоснования задач