QA. Как навести порядок на проекте, в котором есть проблемы (Часть 2)

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

Приветствую всех.

Наконец-то дошли руки до продолжения этой темы.

Первая часть лежит тут.

Следующее о чем хочется поговорить, так это о макетах.

Чаще всего, я видел макеты в подобных состояниях:

  1. Актуальные макеты, относительно того релиза, когда фича появилась на свет(в прод).

  2. Макеты, которые были на этапе первой итерации тестирования

  3. Макеты, которые остались на уровне первой версии и на это поставили задачу "Обновить до актуального состояния"(и как не сложно догадаться, задача положена в бэклог с самым низким приоритетом)

  4. Макета нет

Сложный путь

В первых 2х случаях, можно с помощью pixel perfect и подобных инструментов, примерно понять насколько макеты актуальны. Или любым другим удобным вам способом. Сам же чаще всего использую подход сценарного тестирования. При написании сценариев смотрю только на макеты.

Когда нахожу несоответствия - завожу дефект. Так же стоит отдельно отметить, что лучше всего под такое сделать родительскую задачу/историю/эпик(кому как удобно). Ну и в итоге - иду с этим к дизайнеру/UX. Чаще всего, подобные задачи висят очень долго(если не вечно). Но даже в таком случае мы получаем профит, потому что:

  • Получили информацию об актуальности UI

  • Если к нам придут с вопросами "А почему у нас макет отличается, от того что в проде?", то спокойно даем ссылку на дефект

  • Написали/скорректировали тестовые сценарии

С пунктам 1 и 2 вроде бы все просто. Но давайте подумаем что делать с 3 и 4?

Простой путь

Со случаями 3 и 4 все намного проще. Потому что тестировать макеты смысла нет. Потому что:

Если вся команда забила на макеты и просто игнорирует их существование, то какой смысл?

Из этого можно сделать просто вывод, что фокус у команды совсем другой.

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

Может показаться, что мы ничего не сделали с теми макетами что есть. И да, не показалось. Потому что можно очень много времени потратить на сравнение, но пользы будет мало.(если вообще будет). Но свой профит мы все равно получили:

  • Стало понятно, что пользы от макетов нет и надо сосредоточится на исследовательском тестировании

  • У нас на руках критические и высоко приоритетные сценарии

Да, для своего успокоения, можно спросить на счет поддержки актуальности макетов у команды. Но чаще всего будет тишина или какая-то стандартная отговорка вида: "У нас есть более приоритетные задачи".

Источник: https://habr.com/ru/articles/865532/


Интересные статьи

Интересные статьи

Тема преимуществ открытых табличных форматов при работе с озерами данных всё чаще поднимается в среде дата-инженеров. Предполагается, что их использование способно устранить недостатки популярного Apa...
Представьте: горячий металл, мощные машины, сотни работников — наше производство постоянно подвержено различным рискам. И как мы превратили эти вызовы в возможности? Этот рассказ будет о том, как мы в...
Специалисты российской AI-компании Smart Engines представили две научные работы на ведущей международной конференции в области анализа и распознавания документов ICDAR-2024, проходившей с 30 августа п...
Начнем с небольшого предисловия. Битрикс24 позволяет автоматизировать множество разных процессов внутри компании. В частности в Битрикс есть большой и сильный блок автоматизации процессов работы с кли...
Добрый день! Хочу поделиться своим опытом по миграции Корпоративного портала и CRM Битрикс24 с одного физического сервера на 2 виртуальные машины.В связи с нарастающим количеством заявок программистам...