пятница, 24 июля 2015 г.

Классы эквивалентности: будни Золушки

Позор тебе! — кричит начальник, найдя в приложении баг. Даже если не кричит, все равно стыдно: как я могла пропустить такое? Это же так очевидно, почему же не учла? Потому что не подумала об этом классе эквивалентности.

Искать классы эквивалентности сложно даже мне, тестировщику с 7+1-летним опытом — что говорить о моих студентах. В книгах и на лекциях ребятам все понятно. Но как только доходит до практики, начинается ступор. Как же их искать, классы эти? Я придумала аналогию с диснеевской героиней — Золушкой. Ребята говорят, лекция стала понятнее.

Будни Золушки


Мачеха рассыпала на полу гречку и овес, перемешала и сказала — «Разбирай!». Золушка три часа раскладывала кучки. Итог мучений — гречка к гречке, овес к овсу.

mixed-groats-image.jpg  mixed-groats-macro-17517869.jpg
                           ↓
Рисунок4.jpg
В каждом мешке своя крупа  — свой класс эквивалентности

В тестировании то же самое: выделяем классы эквивалентности (крупу), ищем исключения, перепроверяем. Результат — ошибки находят тестировщики, а не начальство.

Выделяем крупу

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

Протестируем поле ввода имени при регистрации.

Имеет ли смысл вводить «Маша» и «Ольга»? В окне приветствия будут отображаться разные имена, но мы проверяем распространенные женские имена. Если регистрация работает на одном примере, на втором наверняка тоже. Кидаем к гречке оба: они в одном классе эквивалентности

А что насчет «Ивана»? Тоже распространенное имя, но мужское. А что, если система после регистрации присылает письмо «Уважаем(ый/ая)...»? Тогда реакция на разный пол должна быть разная. Кидаем к овсу, это уже не гречка, а другой класс эквивалентности

А что насчет «Розалинд Аруша Аркадина Алталун Флоренс Луна» ? Берем максимально большое имя, которое влезает на экран. Что будет? Мы предполагаем, что оно может вылезти за границы экрана. Кидаем к чечевице, это уже не гречка и не овес, а другой класс эквивалентности.

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

Ищем исключения

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

Я ввожу в поле «имя» формы регистрации: “Ольга” или “Маша”.
Нет разницы.

Снимок.PNG

То, что все значения внутри класса одинаковые — обман зрения. Невозможно найти все баги в приложении или разобрать 2 миллиона крупинок и ни разу не ошибиться. Среди гречки попадается чечевица!

Снимок2.PNG

Вспомним поле ввода имени.
«Максим» и «Иван» — распространенные мужские имена, один класс.
Но при проверке «Максим» работает, а «Иван» — нет. Нельзя вводить меньше 5 символов. Или нельзя вводить имя «Иван».

Месяц назад мои коллеги зашли на сайт банка Х и попробовали оставить заявку на кредит. Ввели ФИО и получили отлуп — «Имя «Иван» вводить нельзя». И фамилию «Иванов», и отчество «Иванович».

Разработчики поставили защиту от тестовых данных — «Иванов Иван Иванович» вызывает подозрение. Но только условие связки компонентов выбрали OR, а не AND и нельзя было быть даже просто Иваном… Если фамилия Иванов ИЛИ имя Иван ИЛИ отчество Иванович — получай ошибку! Вам смешно, а это разные классы эквивалентности!

Мы выделили класс эквивалентности, мы собрали мешочек гречки и сказали, что здесь все идентично. Но мы могли ошибиться, что-то забыть, что-то не заметить. И именно поэтому мы должны все время использовать разные значения. Выделили для поля с именем «распространенные мужские имена», сегодня вводим «Иван», завтра «Максим»…

Перепроверяем

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

Даже если приложение работает одинаково на любых строках, даже если в требованиях говорится, что разницы между «Анной» и «Анной-Марией» нет, а мы все равно сомневаемся — проверяем. Требования — одно, код — совсем другое. Разработчики тоже ошибаются, вместо «только имена» читают «только одно слово с именем» и ставят ограничение на двойные имена. Или додумывают требование, что длинне 6 символов имен не бывает.

Лучше перебдеть, выполнить 20 тестов и найти баг, чем выполнить 10 и продолбать проблему.

Резюме


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

  1. Подумайте, какими бывают «тестируемое поле».
  2. Представьте, какими не бывают  «тестируемое поле».
  3. Поищите границы.

Из кучи возможных значений выделите группы классов эквивалентности


Домашнее задание


Проверка номера кредитной карты — как будете тестировать?

Наводящие вопросы:
  1. Каким чаще всего бывает номер?
  2. Каким он точно не бывает?
  3. Можно ли его писать и слитно, и через несколько пробелов?
  4. Что, если пробелы будут в «неправильных» местах?
  5. Что, если в номере будут буквы?
  6. Что, если номер будет пустой?
  7. Что, если номер будет длиннее положенного?
  8. Что, если номер будет из сплошных нулей?
  9. ...

PS — статья написана в помощь моим студентам, картинки позаимствованы из лекций, интернета и от моей художницы Вики :-)

Поздравляем Александра с новой работой!

Минутка success-story от моих выпускников (smile)
Вчера вечером в чатике выпускников появился Александр с радостной новостью^

Всем привет!

Хочу поделиться радостной новостью - меня взяли в компанию Х (party) 

И в этом немалую роль сыграл этот Интенсив. Думаю без этих практических навыков бы не прошел. Отдельное спасибо Ольге и Павлу, конечно!



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

Интенсив дает понимание в общем и уверенность в себе. 

Также спрашивают, какой практический опыт работы есть, какие проекты. Одно дело, когда ты приходишь и говоришь, что почитал книжки и посмотрел видео. Другое дело, когда говоришь «Я целую неделю по 10-12 часов в день тестировал web сайт проекта серьезной российской компании... И вот моя state & transition diagram by the way...»

Диаграмма произвела легкий шок — вначале пытались разобраться, потом отложили «Слишком сложно, посмотрим позже». 

Ну и в резюме ссылка на проект, конечно, выделяет из остальных.

Могу выделить два основных момента, на мой взгляд:
1) Статус в резюме (пусть и короткий, но серьезный проект).
2) Этот курс дает возможность «переварить» всю теорию, которую смотрел и читал, разложить все по полочкам, иначе в голове каша.

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

Такая вот история! И отличный кейс — я то советую своим ученикам давать чек-лист как пример своей работы, а Александр показал ДЗ8 — state & transition diagram. Тоже вариант, почему бы и нет (smile)

Разумеется, примера работы и заявления «я работал на серьезном проекте» недостаточно. Нужно быть именно выпускником, прошедшим все круги ада и сдавшим все ДЗ. Если не сдавать ДЗ, но сделать диаграмму или чек-лист, быстро зафейлятся на вопросах собеседующего. Ведь главное на нашем курсе — не ссылка на сертификат, а тот минимальный опыт, который вы нарабатываете :)

PS — Пополнила этой статьей историю развития курса, приходите к нам 3 августа!

четверг, 23 июля 2015 г.

Музейный тур. The Museum Tour

Входит в «Туры по историческим районам», Tours Through the Historical District


Вольный перевод статьи Виттакера из книги Exploratory Software testing. Туры помогают искать баги, взглянув на систему по-новому. Тестировщик выбирает тур и следует его цели, не отвлекаясь ни на что другое. Словно турист в незнакомом городе, составил план и пошел!


Музеи с антиквариатом — любимое место туристов. Они собирают несколько тысяч посетителей в день. Антиквариат в коде залуживает такого же количества внимания от тестировщика. В данном случае под антиквариатом мы понимаем legacy code («устаревший код», распространенное название, поэтому оставила без перевода).


-Русский_Музей-,_картинный_зал,_г.Санкт-Петербург.jpg
Legacy code — антиквариат разработчиков


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


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


Если не верите — попробуйте вернуться к багам, которые написали год-два-три назад. Или тест-кейсам. А теперь представьте себе разработчика =) Даже если он писал этот код, он уже 10 раз забыл, что там написано и как, потому что теперь использует совершенно другие, новые, модные, менее бажные паттерны разработки.


Цель тура
Найти старый код в системе контроля версий, который:
— давно создан и больше не менялся;
— давно создан и недавно обновился.
И протестировать функциональность, заложенную в код.


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


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


В этот раз примера не будет по понятным причинам =)


Но по опыту могу сказать — даже если вы все документируете и покрываете автотестами, при использовании функции, которая написано давно и никогда доселе не юзалось — перепроверьте ее! Честное слово, очень полезно =)



PS: студентам моего курса по тестированию во время обучения эта статья не поможет, но вот выпускникам во время реальной работы — очень даже!

четверг, 16 июля 2015 г.

Баги повсюду. Сборная солянка

Новички всегда спрашивают — где получать опыт? Где искать баги?
А опытные, блин, на эти баги напарываются чуть ли не на каждом шагу. Да и новички напарываются, просто забывают.

Я хочу показать, как можно замечать проблемы в повседневных вещах. И не просто замечать, а попробовать локализовать, докопаться до сути. Как «красиво» описать баг разработчикам, используя шаблон — чтобы это была не стена мыслей, а простые и понятные шаги для воспроизведения. Какими тестами можно было найти эту проблему — это самая интересная часть! Ведь даже если конкретный баг вам неактуален, чек-лист по поиску может навести на мысли Wink ;)

Я создала лейблы «баги повсюду» и «панбагон» (когда он восстал из пепла в виде группы на фб) и с этих слов начинаю все описания багов, найденных в повседневных вещах. Плюс создала этот пост, агрегирующий все найденные проблемы вместе =)

Тут нет и врядли будут баги по защищенности. Хотя бы потому, что я не эксперт Smile :)
Но я хочу показать, что баги — они действиетльно повсюду. И в приложениях, и в игрушках, и в интернет-магазинах... Ищите, и найдете =)

Кейсы по локализации


Баги


Web

Кинотеатр
Тестируем регистрацию на сайте Люксор
NaN при выборе сеанса Перегрин на 10.10 в 16:45
Как кинотеатр зажал мои билеты
Nginx error при просмотре программы лояльности

Интернет магазин Wilberries
Поехала верстка в фотках и это закешировалось
Сообщения об ошибках — тоже документация, тестируйте их!
Смайлики криво логируются в ленте новостей
Не user-friedly сообщение об ошибке при загрузке файла
Найди некорректное сообщение по тексту ошибки
Идеально работает по ТЗ ≠ правильно
Ошибка входных данных, если выбрано 0

Другие интернет магазины
Декатлон. Фамилия вводится КАПСОМ

Баги в письмах
Sysdate вместо Fly_date в напоминалке
Оплатите наш счет до вчера

среда, 15 июля 2015 г.

Тур по плохому району. The Bad-Neighborhood Tour

Входит в «Туры по историческим районам», Tours Through the Historical District

Вольный перевод статьи Виттакера из книги Exploratory Software testing. Туры помогают искать баги, взглянув на систему по-новому. Тестировщик выбирает тур и следует его цели, не отвлекаясь ни на что другое. Словно турист в незнакомом городе, составил план и пошел!

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

CjlR2Ru0dM4.jpg
Некоторые места лучше обходить стороной… Но не в коде!

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

Используйте баг-трекер для анализа. Посмотрите — в каком компоненте больше всего ошибок? Там и ищите!

111.jpg
Баги общительны…

funny-homer-simpson-chasing-spider-box-animated-gif-pics.gif
Где один, там их много =)

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

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

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

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

В этот раз примера не будет по понятным причинам =)

>> Тут будет ссылка на следующий тур

PS: студентам моего курса по тестированию во время обучения эта статья не поможет, но вот выпускникам во время реальной работы — очень даже!

понедельник, 13 июля 2015 г.

Тест-кейс VS чек-лист в картинках.

Чем же они различаются?

Официальная часть
Вроде все понятно:

тест-кейсы — подробно;
чек-листы — кратенько.

Но моим студентам все равно тяжело. Зачем в тест-кейсе писать, что именно за файл создается, как его загружать в систему (на какие кнопки нажимать, какие действия выполнять)?

Идея 1


Я предложила им такое пояснение:

Тест-кейсы тупые до невозможности, словно ребенка на работу привели и показываем, "Вот мамочка сейчас файл обработает. Нажимаем кнопочку А, потом кнопочку Б, потом...", а не просто "Ну вот загрузили и все получилось".


Ну а чек-листы — это когда не нужны все эти подробности, как именно мы загружаем файлы, на какие кнопочки нажимаем. Нужна просто напоминалка — «Проверить загрузку Excel, CSV, JPG...»



Ребятам пояснение очень понравилось Smile :)
Сказали, что так понятнее, так что заносим в теорию в картинках!

Идея 2


Вы делали ремонт? Покупали шкафы, собирали их? А я делала и отсюда у меня вторая ассоциация.

Мы купили комод в ИКЕА. Он небольшой и простой в сборке. Но инструкция выглядит как талмуд — все настолько подробно. Каждое действие, каждый шаг. Каждый винтик — все в новом пункте на пол-листа А4, максильно доступно. Такой комод соберет даже полный профан. Потому что ребята не считают нужным пропускать этапы как «Ну это же очевидно, куда ввинчивать этот шуруп». Очень напоминает «Ну это же очевидно, на какую кнопочку нажимать, чтобы загрузить файл» Smile :)


А вот диванчик в коридор мы купили в другом месте. Он тоже небольшой и не сильно сложный в сборке — кубик шкафчика собрать и прицепить к самому диванчику. Но инструкция — полный швах. На ней ровно одна картинка — уже собранный диванчик, все детали чуть на расстоянии друг от друга. Ну это же очевидно, как его собрать!


Мы, кстати, не осилили, оставили мастеру Smile :)

Но разница «Простая инструкция — инструкция из ИКЕА» === «Чек-листы — Тест-кейсы». Когда будете писать тест-кейс, помните об этом и о том, что очевидное вам — темный лес для кого-то другого...

PS — блог-пост добавлен на Testbase в раздел «Теория в картинках», где вы всегда его сможете найти! :-)

Развитие интенсива-14.


С момента прошлых хвастов прошло 2,5 месяца — 2 коротких курса и 2 длинных. Что мы сделали для студентов за это время:

Багред

http://bugred.ru/ — сервис для проверки названий багов.

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

Инструмент полезен в первую очередь мне и моим студентам. Но и не только. Именно поэтому я решила «расшарить знания» на всех и сделала Багред доступным обществу Smile :)

Это абсолютно бесплатный инструмент, решающий конкретные цели. Поэтому он не будет обладать искусственным интеллектом. Но от него и не нужно, ведь это уже уровень сильно выше =) Наша задача — базовые знания Wink ;)

Перевод туров

The FedEx Tour.
Интеллектуальный тур. The Intellectual Tour.
— Внеурочный тур. The After-Hour Tour.
— Сборщик мусора. The Garbage Collector Tour.

Статьи

— Ошибка, дефект, сбой
— Как стать тестировщиком, с чего начать
— Сообщения об ошибках — тоже документация, тестируйте их!
— Публичная подсказка к ДЗ6 Smile :)

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




четверг, 9 июля 2015 г.

Лайфхак. Оформление автотестов в confluence, основная страница

У нас есть пачка автотестов на основной функционал системы. Тесты разделены по разделам, вот тесты на сервисы, вот на задачи...

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

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

Функционала много, тестов много — основная страница не актуализируется и устаревает. Но ладно еще устаревает, можно контролировать и обновлять. Но как сопоставить описание с папочками с коде? Длинную русскую фразу и короткое слово на английском?

Тесты на регистрацию — register 
Редактирование профиля в личном кабинете — edit

Названия вроде простые, но поверьте, в реальном проекте сопоставление очевидно далеко не всегда. И когда находишь тесты в вики, надо потом смотреть по коду и искать название той подпапочки, которая больше всего подходит под описание. Неудобно Sad :(

А как удобно? Мне пока больше всего нравится такое решение:

1. На основной странице (у меня это «Unit тесты») делаем простой Children Display, выставив ему галочку «Include Excerts»




Если вы не знаете, где взять Children Display, то см пояснялку в пункте 2. Children Display — такой же макрос, как Excerpt.

2. В дочерних:
  • Название страницы — название папки в коде.
  • Заголовок внутри Excerpt — фраза на русском языке с пояснением, что именно тут проверятся.

То есть нажимаем «Create», стоя на основной странице тестов, в списке выбираем «Blank Page» → у нас создается страница, дочерняя к «Unit тесты».

Нажимаем «+ Insert — Other macros»


Выбираем макрос Excerpt.



Пишем внутри него описание, можно оставить текст параграфом, но мне нравится в виде заголовка. Меняется тип текста на панели инструментов. 



3. Профит! Smile :)
На главной страничке мы сразу видим структуру кода с пояснениями. Страницу не надо редактировать при добавлении или изменении дочерних


вторник, 7 июля 2015 г.

Буквы в телефоне — баг?

Покупала я тут недавно сертификат на «Ужин в темноте».

Выбираешь сертификат, нажимаешь «Заказать» — отображается корзина.
Проверяешь, все ли правильно, нажимаешь «Оформить заказ».

И видишь такую формочку

Форма ввода данных

Ее заполнение вызвало у меня небольшой диссонанс Smile :)

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

Форма говорит, что имя корректное, ура!


Начинаю набирать телефон и смотрю на экран — смогу ли я ввести свой номер как мне удобно или тут маска ввода зашита?

Поясню, мой номер выглядит примерно так: 8 (926) 22-33-456.
Именно так я его и помню, так всегда и называю, когда просят мой номер. И когда меня просят его проверить и называют 8 (926) 223-34-56, это немного коробит. Непривычно, приходится в уме прикидывать, он или не он.

Поле ввода может быть простым текстом, может быть маской. Так что я смотрю на экран, что мне покажется там?

Начинаю ввод и...

Минуточку... Телефон корректный?

Минуточку! Какая галочка? Я еще ничего не ввела!
Почему один символ считаем корректным вводом?

Во мне тут же проснулся тестировщик и попробовал ввести одну букву — тоже работает!

И этот корректный???

Бегом оформлять баг? Wink ;)

Нет уж, давайте разберемся.
Откуда у меня диссонанс — я работаю с данными. Мы умеем проверять качество введенных данных и по Дадате моя картина мира:

  • Зеленая галочка — данные корректные;
  • Красный восклицательный знак — данные плохие;

Зеленая галочка = корректно, в моей картине мира

Но, если ставить баг или улучшение, его нужно продумать.  Какой результат мы ожидаем?
Начинающие тестировщики хором кричат, что на поле надо повесить маску или запретить вводить символы. Говорю не понаслышке — раньше в Дадате тоже была форма для ввода телефона без всяких масок и мои студенты каждый курс предлагали ставить проверки и ограничения.

Но давайте посмотрим с точки зрения простого пользователя. Мы не любим запретов, они нас бесят. Ведь зачем все эти ограничения? Чтобы типа помочь «не ошибиться». Но вот только если мне помощь не нужна, я найду способ ее обойти. Вот, допустим, телефон. Ах, вы мне запретили вводить что-то кроме маски? Ну и звоните по общему телефону в нашу компанию, перебьетесь без добавочного.

В Дадате была форма с вводом имени и номером телефона. А куда писать доп инфо? В телефон! Так и пишем: «8 800 2223344, звонить после 11:00» или «8 (495) 222-33-44, доб 4455, звонить до 18:00». Сможем мы перезвонить человеку? Сможем! И не нужны никакие маски. И не нужно ограничивать возможности ввода.

Но как же так? А вдруг пользователь ошибется и введет 10 или 12 цифр вместо 11? И не заметит! О ужас и кошмар, мы ему не перезвоним, пользователь обидится и затаит кровную месть. Встречный вопрос — а если он введет 11 цифр, но ошибется в одной? Все равно ведь мы этому пользователю не дозвонимся, а как система такую ошибку найдет?

Никогда не запрещайте. Система может подсказывать пользователю информацию в его мире. Может помогать не ошибаться. Например, если мы «принимаем» только мобильные телефоны в России, то можно и маску на поле повесить. Но всегда стоит задуматься, а действительно ли эта информация нам жизненно необходима? Может, сделать поле необязательным? Или расшифровать — зачем собираем информацию. Вот как выше на картинке, поле с id в ВК необязательно, но, заполнив его, получаешь плюшку! Вот это я понимаю, стимул для заполнения Smile :)

В случае же ввода телефона в «Ужине в темноте» бага нет. У них есть несколько полей. Я могу ввести только свое имя и адрес доставки и не оставлять телефон и email. Им он и не нужен, это нужно мне, если я хочу, чтобы курьер мне отзвонился. А если не хочу, то и ничего и не ввожу или пытаюсь обмануть лишние проверки.

Конечно, в таком случае можно вообще не рисовать восклицательные знаки и не требовать заполнять поля, в которые можно просто везде нулей понаставить. Было бы лучше убрать знаки и подписать каждое поле, зачем мне, пользователю, нужно его заполнять, Но не «выводить ошибку, если поле заполнено неправильно». Как-то так :-)