Что должен сообщить тестер?

Question

У меня есть веб-сайт, который я создаю для клиента. Теперь у меня есть тестер проекта.

Я чувствую, что нужны тестеры. ДЕЙСТВИТЕЛЬНО! Я не могу проверить свой собственный код. Я также ценю ценность нового набора глаз. Но что хочет сообщать?

Легко сказать, что обо всем нужно сообщать, но у меня нет кого-то между мной и тестером, чтобы отфильтровать несущественные запросы. Тестер плохо знает ни систему, ни целевого пользователя. Она ставит мне задачи, а не руководитель проекта. Я думаю, что это скоро изменится, но, пока это не произойдет, что вы рекомендуете? Кажется, есть мнение, что наши пользователи НИКОГДА не использовали интерент раньше, и они такие же тупые, как камни.

Проблема, с которой я столкнулся, заключается в том, что ВСЕ, что предлагает тестер, принимается автоматически и присваивается мне.

У меня есть много случаев, которые заставляют меня опустить челюсть и сказать: «Правда? Ты серьезно? Это заслуживает того, чтобы быть проблемой?»

Пример: необходимо добавить текст вверху страницы с надписью "* = Обязательный" для обязательных полей.

Вы когда-нибудь чувствовали это так? Как ты с этим справился?

Пока я просто делаю, как мне говорят, но я проясняю, что я не согласен.

Answer 1

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

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

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

Answer 2

Вам необходимо добавить приоритеты для ваших вопросов. Это позволит вам решить важные вопросы в первую очередь, а косметические - последними. Вот пример приоритетов от Jira:

• Приоритет 1 - воспроизводимый сбой; блокировать любые дальнейшие испытания или разработку конкретной функции; потеря постоянных данных пользователя; огромная утечка памяти
• Приоритет 2 - серьезная проблема, которая должна быть устранена до выпуска продукта; запрещает пользователям использовать функцию; негативно влияет на партнера; значительная утечка памяти в часто используемых функциях
• Приоритет 3 - небольшая проблема, которая должна быть устранена до выпуска продукта; не мешает пользователям использовать продукт; очень заметная проблема юзабилити; небольшая утечка памяти в редко используемой функциональности
• Приоритет 4 - чисто косметический вопрос; не влияет на функциональность

Answer 3

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

Одна вещь, которую вы абсолютно не хотите делать, это отговаривать тестировщика от регистрации ошибок. Это вернется, чтобы укусить вас, когда что-то полностью сломается, и они скажут: «Я думал, что так оно и было».

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

Answer 4

На самом деле звучит так, будто ваш тестер делает правильные вещи (и текст "* = required" - очень хорошая идея).

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

Answer 5

Сообщить обо всем и сортировать. Через некоторое время она начнет понимать, что проходит через сортировку, а что нет. Люди могут учиться; учить.

Answer 6

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

Надеюсь, у вас есть какая-то спецификация проекта, на которую подписал клиент, чтобы вы знали, когда проект завершен и какие вещи не включены в объем проекта. Если нет, то у вас может быть небольшая драка в ваших руках. Для изменений, которые, по вашему мнению, выходят за рамки проекта, вам, возможно, придется пойти на компромисс - возможно, выставить им счет по более низкой ставке или разделить стоимость с ними. Если вы находитесь в такой ситуации, это хороший учебный опыт, чтобы все документировать в спецификации проекта, чтобы не было вопроса о том, что выходит за рамки проекта. Я был там - одного такого опыта достаточно, чтобы научить вас уделять больше внимания вашим спецификациям.