Вопрос по QA — стандарты оформления и пр
Всем привет.
Подскажите, по стандартам оформления.
Сколько проектов было — в каждом по-разному, но я все-таки хочу понять — существуют ли какие-то общепринятые стандарты для веб-приложений по части юзабилити, если их нет на проекте как таковых.
Пример:
— если нет прав на какое-то действие у пользователя — мы должны прятать кнопку, которая осуществляет это действие или мы НЕ должны ее прятать, а должны «ругаться» вменяемым сообщением что-то типа «У вас недостаточно прав, обратитесь к администратору»?
Если такая тема на форуме была — буду благодарна за ссылки. Я поиском ничего не нашла подходящего.
Спасибо, жду Ваших мнений по этому поводу. Как у вас на проектах? Как Вы считаете должно быть?
Вопрос касается админ.части сайта.
Также, топик можно дополнять своими вопросами. Будет интересно почитать.
30 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівЕсли вы имеете ввиду usability стандарты, то вам сюда www.iso.org/...detail.htm?csnumber=16883
+ к этому пробежаться по известным сайтам — глянуть их структуру, а дальше уже опираться на опыт
стандарты общие, а вот вкусы разные
пробежаться по админкам известных сайтов?)))
ну...если взломать....
да, мой фейл, вы суть почти вконец спрятали :)
в большинстве случаев я склоняюсь к
такое использовать, когда все чётко понимают иерархию:
Если это админка — просто прячем кнопку. Тому, у кого нет прав на действие, лучше и не знать что такое действие вообще технически возможно совершить.
P.S. В англоязычной части веба можно нагуглить статьи по разным вопросам UX/UI, часто очень интересные
www.microsoft.com/...load/details.aspx?id=2695 — Windows User Experience Interaction Guidelines
www.microsoft.com/...load/details.aspx?id=4249 — Windows User Experience Guidelines
guidelines.usability.gov — WEB
Последняя ссылка: как-то не очень доверяю сайтам по юзабилити, где список разделов выглядит так: i.piccy.info/...52520/73928/943537/us.png
Мне в свое время помогла вот эта книга — www.ozon.ru/...ntext/detail/id/16905899
Там есть много примеров хороших практик.
спасибо
Стандартов — нет.3-х представителей для каждой из категорий.
Если надо полноценное юзабилити, то я бы делал так: собрал фокус-группу из людей, которые являются таргет-группой для данной аппликухи (ну, например, если аппликуха бухгалтерская — то собрать бухгалтеров, если игрушка — то геймеров и т.д.), по возможности разных возрастных (и других, если есть критерии для таргет-группы) категорий, дал им приложение на попробовать и собрал отзывы в разрезе: что удобно — что неудобно, что понравилось, что — нет и т.д.
Таргет-группа должна быть не меньше 10 человек (чем больше, тем лучше) и иметь не менее
И устроить большую попойку :)
Таких стандартов не существует.
Если бы и существовали, то здравый смысл всё равно должен верховенствовать.
А причём тут QA до UX? Стандартов железобетонных нет, но есть общепринятые стили и привычные пользователю алгоритмы.
Смотри: каких-то пару лет назад вывалить перед юзером попап на полэкрана, закрывающий доступ к сайту — считалось жутким моветоном. Сейчас же это творят все кому не лень, возможно даже и DOU (лень AdBlock отключать чтоб посмотреть). И ничего, юзеры не просто терпят, а лайкают и шерят как полные идиоты.
UX — по-прежнему область экспериментов. Общее правило одно и не меняется уж сотни лет:
НЕ ЗАСТАВЛЯЙТЕ МЕНЯ ДУМАТЬ
Ну вообще-то в тестировании есть вид тестирования Юзабилити и если нет общепринятых правил на проекте, то решать КАК будет тестировщик, за неимением аналитика. Это я к вопросу «причем тут QA». Притом. И спасибо за ответ.
В данном случае, QA не может говорить «как», а может поднять вопрос\дать рекоммендацию. Простой и вопиющий пример: обычно, если нажать кнопку «удалить», объект не должен быть сразу удален, а должно быть запрошено подтверждение операции. Если его нет — можно поднять вопрос и дать рекоммендацию. Т.к. тестировщик не может знать — это продолб или в данном конкретном случае сделано специально. Опять же, общих стандартов нет, если рекомендации. Нужна читать литературу UX
Аналогично с кнопкой КУПИТЬ.
Речь в теме шла об админ части сайта. Там в принципе не может быть кнопки «Купить». На счет «Удалить» — да, можно и нужно выдавать что-то типа «Вы точно уверены?». Но суть вопроса не совсем в этом.
К примеру есть функция «Копировать запись», но ее отображать всегда или только, когда у пользователя есть на это право? Вы описали немного не те примеры. Как сделано у вас на проектах- вы прячете кнопки или всегда отображаете и выдает сбщ, в случае , если у пользователя нету права на использование этой кнопки?
По литературе по UX — обязательно почитаю.
Это очень распространенный случай и всегда делается кастомно. Самый простой и правильный подход: сомневаетесь в чем-то — пишите письмо\звоните\заводите тикет на UX. Если они заапрувят — ок, ваша совесть чиста. К тому же, UX обычно лучше знают, как более правильно.
Иссключения: если вы долго работаете с системой (обычно qa больше других членов команды проводят с системой), то можете на чем-нибудь настоять.
Я думаю на каждом проекте по своему. Как по мне здесь главное, чтобы это было однообразно, т.е. если принято недоступные кнопку скрывать, то все такие кнопки должны быть скрыты. Т.е. не должно быть такого, что одна часть недоступных кнопок скрыта и при этом другая часть видна, но задезейблена.
Делать все в «одном стиле» — это есть гуд.
Но для функциональности с разным приоритетом поведение может отличаться.
Но, в целом, подход верный.
Тестировщики юзабилити заниматься не должны. «A/B testing» тоже существует, и вроде бы тоже называется «тестированием», ну и что с того?
Все зависит от компании, проекта, структурного разделения обязанностей в проекте. Части один человек выполняет роль нескольких членов команды, либо вообще отсутствует человек на определенную роль (и приходится другому ее выполнять).
Тестировщик не должен принимать решение, но на практике часто именно его мнение (за имением определенных доводов) считается более весомым (косвенное принятие решения). И выходит как ты тестировщик «принимает» решения о мелочах, которые не описаны в ТЗ (если оно есть).
У нас на текущих проектах: часть кнопок «прячется», часть — выводятся сообщения пользователю.
Что такое «юзабилити»?
Как это надо тестировать?
Кого волнует мнение тестировщика о поведнии кнопок, если наблюдение надо делать непосредственно на пользователях?
Юзабилити-тестирование
Данные берутся из соц. опросов и предыдущего опыта тестировщика.
Особенно если разрабатывается сурьезный продукт и тестировщик не в лык ногой. сделает, с его точки зрения, все логично и удобно, а для конечного пользователя — пакріщення абікнавєннає.
Процесс
«При испытании многих продуктов пользователю предлагают в „лабораторных“ условиях решить основные задачи, для выполнения которых этот продукт разрабатывался, и просят высказывать во время выполнения этих тестов свои замечания.
Процесс тестирования фиксируется в протоколе (логе) и/или на аудио- и видеоустройства — с целью последующего более детального анализа.
Если проверка эргономичности выявляет какие-либо трудности (например, сложности в понимании инструкций, выполнении действий или интерпретации ответов системы), то разработчики должны доработать продукт и повторить тестирование.
Наблюдение за тем, как люди взаимодействуют с продуктом, нередко позволяет найти для него более оптимальные решения. Если при тестировании используется модератор, то его задача — держать респондента сфокусированным на задачах (но при этом не „помогать“ ему решать эти задачи)» ©
Где тут тестировщики находятся? Тут тестировщики вообще не нужны.
Наваливать на тестировщиков ответственность за тестирование юзабилити так же плохо и повсеместно, как и наваливать на них ответственность за качество продукта.
Не могу не согласиться с этим. Но, увы, в наших реалиях, да в нашей стране такие случаи сваливания «левых» обязанностей не редки.
Случай (когда отказались от регрес. тесрирования в пользу смоука из-за нехватки времени):
Почему не заметили багу, попавшую в продакшен? Виноваты тестеры!©К слову о размытости понятий о QA/QC/Tester — в ту же оперу.
П.С. Нашел на ДОУ багу :)
Радуйтесь, когда отказываются от регрессии, в пользу смоука.
Проще сделать хотфикс на несмертельный баг, чем 2 недели покрывать 2/3 админки, и потом один хрен — словить пару багов =) (из горького опыта)
Не в ситуации, когда на продакшене сотни тысяч пользователей. Звонок от саппорта = ...
ну проекты разные случаются
посмотрел стату — у меня 420к юзерс/дейли, которые заходят не новости почитать
у Вас видимо бюрократия =)