Сегодня столкнулся с проблемой, когда web-форма работает в IE, но отказывается работать в Chrome (чаще бывает наоборот=).
Неработоспособность заключается в том, что форма не отправляется.
html и js код верный. Повозился некоторое время и в результате понял причину. Дело оказалось в том, что разработчик реализовал по-умолчанию "скрывание" некоторых элементов управления от пользователя. В этом-то и оказался корень зла. Разработчик активно использовал нововведения HTML5 в виде возможности валидировать поля в броузере без js и до отправки на сервер. Речь идет об атрибутах required, maxlength... ( подробнее читать в стандарте )
Скрытые с помощью CSS контролы тоже имели подобные атрибуты, и разработчик ожидал , что броузеры не станут проверять то, что пользователю недоступно.
Ошибся.
Что касается IE, то ему на эти атрибуты вообще было плевать. Поэтому форма благополучно отправлялась.
chrome-же , действуя строго по стандарту, проверял все, не взирая на стили. Неожиданно для пользователя, но вполне логично с точки зрения разработчиков chrome.
Проблема решается, например, добавлением атрибута disabled тем элементам, которые надо спрятать.
Надеюсь, прочитавшие этот пост на подобные грабли не наступят :)
понедельник, 12 марта 2012 г.
"Так никто не будет делать" или защита от дурака
Все мы в цейтноте. Всем не хватает времени. Успеть бы самое важное.
Но тестировщику, который по определению должен быть любопытен сложно запретить ковырять приложение там, где никто не ожидает. И когда он что-то эдакое наковыряет, то часто спешит поделиться результатом с окружающим миром... в виде бага например )
В таких условиях ему часто приходится слышать следующие ответы от разработчиков : "Зачем Вы регистрируете такие баги, ведь в жизни ТАК никто не будет делать!?".
Аргументирует. Доказывает - "Так сделал я, значит рано или поздно так сделает кто-нибудь другой" Иногда с ним соглашаются, иногда - нет. А когда не соглашаются, то , порой потом, бывает, получают такой фидбек: "Ну что же вы , ребята, даже защиты от дурака не сделали. Нехорошо. Не солидно."
Вопрос, стоит ли тратить время на маловероятные сценарии использования или нет? Уверен, что стоит. Да , с учетом приоритетов и предшествующего вылиызвания " основных " сценариев использования.
Сам стараюсь придерживаться следующих правил:
- если речь идет о trusted source, то обращать внимание на "дурацкие" сценарии только в самую последнюю очередь. Например, закрытая админская часть, где пользователь по определению должен быть обучен и не должен быть "сам себе злобный буратина".
- если функционал открыт для широкой общественности, то приложение должено быть максимально предусмотрительным. Тем более, что там где кончается "дурак" часто начинается "вредитель".
- проверять документацию/описание/туториал - действительно ли после ознакомления с ней пользователь будет действительно "дураком" , если сделает так-то или эдак. Часто , причина в "дурацких" действий лежит в неинтуитивности интерфейсов, наложенных на отсутствие внятного мануала.
p.s. ну вот на закусу о "дураках" и "вредителях" - пару месяцев назад был обнаружен критичный баг в Safari . ОТкрываешь iframe с большим значением height и любуешься BSOD-ом. "Дурак" опечатался в "height", а "вредитель" подумал и использовал для выполнения произвольного кода...=)
Так что все как всегда неоднозначно .
Но тестировщику, который по определению должен быть любопытен сложно запретить ковырять приложение там, где никто не ожидает. И когда он что-то эдакое наковыряет, то часто спешит поделиться результатом с окружающим миром... в виде бага например )
В таких условиях ему часто приходится слышать следующие ответы от разработчиков : "Зачем Вы регистрируете такие баги, ведь в жизни ТАК никто не будет делать!?".
Аргументирует. Доказывает - "Так сделал я, значит рано или поздно так сделает кто-нибудь другой" Иногда с ним соглашаются, иногда - нет. А когда не соглашаются, то , порой потом, бывает, получают такой фидбек: "Ну что же вы , ребята, даже защиты от дурака не сделали. Нехорошо. Не солидно."
Вопрос, стоит ли тратить время на маловероятные сценарии использования или нет? Уверен, что стоит. Да , с учетом приоритетов и предшествующего вылиызвания " основных " сценариев использования.
Сам стараюсь придерживаться следующих правил:
- если речь идет о trusted source, то обращать внимание на "дурацкие" сценарии только в самую последнюю очередь. Например, закрытая админская часть, где пользователь по определению должен быть обучен и не должен быть "сам себе злобный буратина".
- если функционал открыт для широкой общественности, то приложение должено быть максимально предусмотрительным. Тем более, что там где кончается "дурак" часто начинается "вредитель".
- проверять документацию/описание/туториал - действительно ли после ознакомления с ней пользователь будет действительно "дураком" , если сделает так-то или эдак. Часто , причина в "дурацких" действий лежит в неинтуитивности интерфейсов, наложенных на отсутствие внятного мануала.
p.s. ну вот на закусу о "дураках" и "вредителях" - пару месяцев назад был обнаружен критичный баг в Safari . ОТкрываешь iframe с большим значением height и любуешься BSOD-ом. "Дурак" опечатался в "height", а "вредитель" подумал и использовал для выполнения произвольного кода...=)
Так что все как всегда неоднозначно .
среда, 7 марта 2012 г.
Тестировщик как ревизор кода или минусы "черного ящика"
Тестирование "черного ящика" , пожалуй, наиболее распространенная практика верификации ПО.
У нее есть свои плюсы , минусы и область применения. Хочу привести пример (буквально по горячим следам), когда одного "черного ящика" явно недостаточно...
До доработки у системы N имелась функция F. Эта функция вызвается из разных "мест" системы. То есть, есть основной сценарий ее использования и более редкие - побочные.
Функция F дополнена функцией f. Эта новая ф-я f ДОЛЖНА выполняться ПРИ КАЖДОМ "вызове" F.
Тестировщик протестировал основной сценарий - все ок. Тест дизайнер, доверяя сисаркам, тем не менее попросил тестировщика провести дополнительные тесты , проверяя "побочные" сценарии использования F. При прверке первого же такого сценария тестировщик выявил то, что новая функция f не вызывается при вызове F. Разработчик исправил , тестировщик проверил. Все ок. Переходит к следующему "побочному" сценарию - там та же история.
Тест-дизайнер смотрит на все это , удивляется и лезет в changeset-ы и, не веря своим глазам, обнаруживает, что с каждым фиксом разработчик копипастит код вызова f и вставляет везде, где вызывается F.
В итоге , разработчику пришлось-таки сделать так, как он по идее был должен сделать с самого начала - убрать код вызова f в код F , тем самым исключив проблему отстутствия новой функциональности во всех сценариях использования.
Не выходя за рамки процесса тестирования можно констатрировать минус "черного ящика", который заключается в риске пропустить подобный "архитектурный" баг. Этот риск тем больше, чем несовершениее процесс управления изменениями в конторе.
То есть, очевидна, польза в просмотре кода тестировщиками: если бы разработчик с самого начала расплодил код вызова в по всей системе, то тестировщик, проверяя все сценарии и, не находя в них ошибок, так никогда бы и не узнал о том, как неоптимально и взрывоопасно все реализовано. А при добавлении нового сценария с вызовом F через некоторое время получили бы проблему "невызова f" с большой долей вероятности.
p.s.
Читайте код, если есть возможность :)
У нее есть свои плюсы , минусы и область применения. Хочу привести пример (буквально по горячим следам), когда одного "черного ящика" явно недостаточно...
До доработки у системы N имелась функция F. Эта функция вызвается из разных "мест" системы. То есть, есть основной сценарий ее использования и более редкие - побочные.
Функция F дополнена функцией f. Эта новая ф-я f ДОЛЖНА выполняться ПРИ КАЖДОМ "вызове" F.
Тестировщик протестировал основной сценарий - все ок. Тест дизайнер, доверяя сисаркам, тем не менее попросил тестировщика провести дополнительные тесты , проверяя "побочные" сценарии использования F. При прверке первого же такого сценария тестировщик выявил то, что новая функция f не вызывается при вызове F. Разработчик исправил , тестировщик проверил. Все ок. Переходит к следующему "побочному" сценарию - там та же история.
Тест-дизайнер смотрит на все это , удивляется и лезет в changeset-ы и, не веря своим глазам, обнаруживает, что с каждым фиксом разработчик копипастит код вызова f и вставляет везде, где вызывается F.
В итоге , разработчику пришлось-таки сделать так, как он по идее был должен сделать с самого начала - убрать код вызова f в код F , тем самым исключив проблему отстутствия новой функциональности во всех сценариях использования.
Не выходя за рамки процесса тестирования можно констатрировать минус "черного ящика", который заключается в риске пропустить подобный "архитектурный" баг. Этот риск тем больше, чем несовершениее процесс управления изменениями в конторе.
То есть, очевидна, польза в просмотре кода тестировщиками: если бы разработчик с самого начала расплодил код вызова в по всей системе, то тестировщик, проверяя все сценарии и, не находя в них ошибок, так никогда бы и не узнал о том, как неоптимально и взрывоопасно все реализовано. А при добавлении нового сценария с вызовом F через некоторое время получили бы проблему "невызова f" с большой долей вероятности.
p.s.
Читайте код, если есть возможность :)
Подписаться на:
Сообщения (Atom)