А требования это вопрос к аналитику или тестировщику?

Это к тому, кто ими на проекте занимается. Никогда в своей карьере не встречал бизнес-аналитика. Хотя говорят, они существуют 😂

Это, на самом-то деле, заблуждение.
Большинство пользователей не способны оценить удобство/неудобство и UX в частности.

Выбрать наиболее удобный им из нескольких вариантов - ещё более менее.
Но оценить удобство - явно нет.

Поэтому только метрики, цифры и слепые тесты с последующим анализом результатов теми, кто в состоянии эти данные правильно анализировать.

Эксперты говорят, что нашим сайтом удобно пользоваться.
Но пользователи говорят, что им неудобно.
Но они же не эксперты!
😂

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

Это, в общем-то, не значит, что тестировщик обязан уметь в юикс, но и утверждение что «об этом пусть другие ребята думают» тоже довольно спорное.

Вот именно, что в данном случае, тестировщик выступает адвокатом пользователей, как бы становясь одним из них или примеряя несколько ролей, но не становясь экспертом в UX.
Это и есть верификация требований, UX и т.п., которые придуманы экспертами.

Я про это и говорил. Что серьезно в "что хорошо для юзеров" играют другие роли, а тестировщик, может лишь помочь, выступая в роли, зачастую, достаточно субъективного пользователя.

Короткая байка на тему юикса:
Однажды к нам в одну из команд пришёл лид одной из бизнесовых команд и попросил юиксных доработок.
Что б рекламные площадки можно было добавлять по несколько сразу, жмакаешь хоткей - открывается ещё одна формочка.

Сделали, юзеры очень довольны, всем хорошо.
Им удобно.

Через два месяца выяснили, что вместо этого можно было добавить загрузку из csv, из которого все это копипастили.
Просто когда посоны придумывали как им будет удобно, они не подумали, что так можно было.

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

всем привет, у Куликова в книге в одном из видов тестирования указано, ‘Демонстрационное тестирование или qualification testing’,  отличия от приёмочного тестирования там указаны, в том что данный вид более всеобъемлющ, вот только сам перевод с английского меня вёл в ступор после чего я решил погуглить и на всякий чекнул в яндексе, почти от слова ‘совсем’ не смог ничего найти про этот вид тестирования

Куликовский 🤦‍♀

К тестировщику)

доброго дня всем. Подскажите, пожалуйста, что имеется ввиду под "группировка багов по месту локализации"

лучше спросить того кто составлял задание

А как ты баги заводишь, в баг трекер? Или в какой нибудь документ (Гугл док, папер ?)

в гугл таблицы

Значит имеется ввиду что надо группировать списки багов в зависимости от "страницы нахождения".

Пример. (есть сайт)

Главная страница
*Список багов на этой странице*

Поиск
*Список багов поиска*

Каталог
*Список багов на странице каталога*

И так далее.

на тестирование дали лендинг...одна страница

Значит - Блоками.

Блок "наши услуги"
Блок "Слайдер"
Блок "Отзывы"

наверно так

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