Раньше наша команда собиралась с определенной периодичностью (обычно раз в 2 недели) и оценивала баги. Приходили менеджер, QA-лид и лид-разработки. Встреча занимала 0.5 - 1 ч. Не всегда успевали все оценить и хвост неоцененных тасок тянулся, и даже что-то терялось. Однажды нашего менеджера осенило оценивать баги через телеграм бота, чтобы (1) в моменте знать насколько критичный баг, (2) не тратить время на встречу и (3) оценивать в любой момент времени. В итоге, запилили логику по схеме:

1. Создаем багу в трекере
2. Трекер вызывает тг-бота
3. Тг-бот отправляет в чат нотификацию "Проставить важность багу" со ссылкой на баг и призывает 3-амиго (менеджер, разраб и тестер)
4. 3-амиго реплаят сообщение бота цифрами от 1 до 100, где 1 - блокер, 100 - когда-то однажды поправим.
5. После того как оценку проставили все амиго бот находит среднее и проставляет багу важность. Кстати, есть опция - если хотя бы один оценщик поставил оценку и отправил реплай "стоп", то бот берет имеющиеся оценки, находит среднее и проставляет багу важность.
6. В трекере ранее создали фильтр куда попадают таски отсортированные по важности.

Что вышло

Из плюсов:

1. Мы избавились от неоцененных багов,
2. В канале обсуждаем почему такая оценка, влияние и т.п. Кстати, из-за обсуждений сокращалось кол-во оцененных багов во время встречи.
3. Сэкономили ~2 ч. в месяц :),
4. Фичу начали использовать другие команды, а еще экономия времени (супер!)
5. Кстати, кто-то из команд начал использовать тг-уведомления, как нотификацию о заведенных багов.

Из минусов:

1. Столкнулись с проблемой, что в потоке нотификаций теряются таски на оценку или кто-то из амиго не проставляет важность, а значит снова не оцененные таски :(
2. Не подумали, что должна быть возможность переоценивать багу, пока не проставили оценку.

Что делаем дальше

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

И как говорится "на правах рекламы" подписывайтесь на мой тг-канал "Тестировщик", делитесь бустами и оставляйте комментарии :)

Logcat - инструмент для сбора логов с устройства / приложения. Логи можно разбить на категории по тегам, уровням и процессам. Также в интерфейсе Android Studio можно фильтровать логи, искать по вхождению или с помощью регулярных выражений. Подробности про Logcat можно прочитать в официальной документации.

Как найти Logcat

1. В UI-интерфейсе в Android Studio: View > Tool Windows > Logcat или option+6 (Mac).
2. Через терминал: Terminal > adb shell logcat . В этой доке рассказываем про UI-версию. Про CLI-версию можно прочитать тут.

Уровни логов

Каждый лог имеет дату, время, процесс, ID потока, название пакета, приоритет и сообщение. Для удобства уровни логов выделяют цветом и лейблом. В таблице типы представлены от низшего к высшему типу.

Фильтры

Фильтрация логов по уровням

Для фильтрации логов по уровням необходимо в инпут фильтрации ввести пару level:<type>, где type - уровень логов. Нужно учитывать что включая лог низшего уровня увидим сообщения типа высшего уровня. Т.е. включить логи W, то в логах увидим и E, A. Если включить V, то будут отображаться логи всех уровней.

Фильтрация логов по тегам

Тег - это параметр передаваемый в функцию Log.<log_level>, с помощью которого можно фильтровать события только с таким тегом. Чтобы искать по тегу, нужно в инпут фильтрации ввести tag:<entry_type>. Например, чтобы увидеть события андроида можно ввести tag:android

При вводе tag можно увидеть предложенные варианты поиска, в том числе можно исключать теги конструкцией -tag:<entry_type>

Фильтрация логов по пакетам

Фильтрация по пакету (приложению) аналогична фильтрации по тегам. Нужно задать конструкцию package:<package_name>. Например, отфильтровать запрос по пакетуpackage:android.hardware.graphics.allocator@3.0-service

Комбинация фильтров и регулярные выражения

В инпуте фильтрации можно использовать регулярные выражения. Например, вот так package:android | -package:system_processможно отфильтровать события с пакетом android и отбросить события system_process.

Некоторые дополнительные возможности logcat в Android Studio

Экспорт и импорт логов

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

Чтобы прочитать экспортированный лог нужно кликнуть на пиктограмму:

Раздельный просмотр логов

Удобно разделять окна логов, например, в одном смотрим какие логи приходят с устройства, а на другом какие логи были импортированы. Для этого жмем на пиктограмму и выбираем способ разделения, а далее в выпадающем списке источник логов:

Перенос строк для удобства чтения

Для удобства чтения, чтобы не скроллить длинные строки, включаем Soft-wrap:

Работа с логами через CLI logcat

Подробнее про возможности CLI logcat читайте в официальной документации. Ниже представлены некоторые из них:

1. adb logcat - вывод логов в реальном времени в терминал
2. adb logcat >> <path/file.txt> - сохранение логов в файл, где <path/file.txt> - путь и название файла с логами
3. adb logcat '*:<level>' - вывод логов определенного уровня, где - V — Verbose, D — Debug, I — Info, W — Warn, E — Error, F — Fatal
4. adb logcat -c - очистка логов

В этом посте узнаешь про распространённые ошибки, какие повстречал, как их увидеть, как с ними бороться и к чему приводит их допущение.

1. Кто-нибудь заведёт

Что значит: заметить баг и не завести на него тикет или не убедиться, что он заведён. Чаще всего думают так: «явный баг, кто-нибудь заведёт» или «100% на это есть тикет».

К чему приводят: баг незначительный, но так какявно виденбольшой аудитории, то это причина перенести релиз, завернуть сборку и прочие нехорошие последствия.

Как увидеть: это как раз баги лежащие на поверхности и чаще всего это баги графического интерфейса. Съехавшие кнопки, опечатки в тексте, битые ссылки - это все и есть баги «кто-нибудь заведёт».

Как бороться: ключевая причина проблемы - лень. Все ленятся, и тестировщик не исключение.

Чтобы не стать жертвой этой ошибки нужно:

• Если лень искать баг, написать в чат команды. Так обозначишь проблему и возможно тебе скинут ссылку на заведённый баг. Возьмёшь обязательство перед коллегами, завести баг, и лень уже не победит.
• Давать четкие однозначно описывающие названия багам. Такие баги легко ищутся в багтрекерах. Если не нашел, значит нужно заводить.

2. N-багов в одном тикете

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

К чему приводит: чинят один, другие остаются. Тратится время на сборку, тест, возврат на починку и нормальное переоформление. Это приводит к сдвигу релиза, переработкам, ухудшению качества тестирования.

Как увидеть: множество несоответствий в фактическом результате, например: «фактический результат: съехала кнопка, текст не соответствует действию, возвращается 500-код по клику».

Как бороться:

• Перечитывать фактический результат. Если несколько дефектов - разбить баг на несколько.
• Мелкие баги графического интерфейса или функциональные можно объединить в одном баге. Например, «цвет кнопки серый и текст съехал» или «в json нет timestamp и date приходит пустой». Но лучше так не делать. Особенно когда ты новичок или проект только начался (можешь не все понимать, лучше завести и закрыть после).
• Если просит менеджер или лид завести в один - заводи. Но обязательно прописывай каждую ошибку и выделяй, подсвечивай, обводи и т.п. Главное, чтобы невооруженным глазом было видно - в баге несколько проблем! Но the best практика - отстоять свою позицию и завести несколько багов.

3. Артефакты в публичном доступе

Что значит: сохранять скриншоты, скринкасты с незарелизенным функционалом в открытом доступе, не ограничивать доступ к ТЗ в гугл-доках.

К чему приводит: в СМИ появляется инсайдерская информация, убытки компании, сорванный проект, обида команды.

Как увидеть: к сожалению такие вещи сложно отследить. Для этого существуют сисадмины, которые должны контролировать ПО и действия с помощью групповых политик в домене.

Как бороться:

• В настройках любого ПО проверять не сливаются ли файлы в общий доступ
• Проставить в гугл-доках, любых других аналогах - доступ по умолчанию закрыт
• Не рассказывать, не делиться ссылками по секрету с друзьями, бывшими коллегами и т.п.

4. Искусственное тестирование

Что значит: тестировать на искусственных данных позабыв про использование реальных или похожих на реальные.

Также сюда входит очень тонкий момент - тестирование на проде. Нужно тестировать на проде, но очень аккуратно, и главное помнить, что нельзя ничего трогать глобального (только в рамках тестового пользователя) и без 100% уверенности, что это ничего не сломает.

К чему приводит: пользователь получает продукт, который не будет работать в реальных условиях, а значит бесполезен.

Запуск проекта или релиз новой версии без тестирования на проде это очень редкий кейс, но если имеет место, то часто функционал не запускается (не те пути к базам, нет доступов у пользователей и т.п.)

Как увидеть: чаще всего при тестировании функционала реальными данными или похожими на них появляется больше багов. Если у тебя подозрительно мало багов, то стоит подумать, а используешь ли правильные данные (реальные, похожие).

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

5. Тестировать в проде

Что значит: значит проходить тестовые кейсы в продовом окружении и оставлять после себя артефакты, который могут увидеть пользователи. Например, тестируешь интернет-магазин и оставляешь после себя товары с названием "Тестовое тесто".

Но самое ужасное, если у тебя есть доступ к CRM, базам данных и т.п. и ты ненамеренно удалил что-то важное, например базу с пользователями.

К чему приводит: в лучшем случае никто не увидет или увидит забавную карточку товара, а в худшем засветишь тестовые данные учеток или испортишь внешний вид сайта.

Про тот случай, когда есть доступ к CRM и базам, не буду описывать последствия - они понятны.

Как увидеть: обращай внимание на URL-сайта, какая используется база, какой серверный конфиг и прочие атрибуты окружения.

Как бороться: есть много способов:

• создавать виртуальные машины с соответствующим окружением,
• создание профилей для продовой и тестовой среды,
• давать права тестированию только на чтение в проде,
• разворачивать тестовую среду на отдельных URL, серверах и т.п.

6. Боятся задать вопрос

Что значит: не спросить побоявшись выглядить глупым.

К чему приводит: функционал не протестирован полностью, пропущены критичные баги.

Как увидеть: считаю что есть 2 основные причины

1. Коллеги считают что ты должен все знать
2. Нет 100% уверенности в правильности понимания задачи

Как бороться:

• В случае с коллегами стоит запомнить "спрашивать - твоя работа, не важно , сколько раз, и не важно кажется ли тебе вопрос глупым".
• В случае с неуверенностью перечитай ТЗ, тикеты, переписки и задай вопрос коллегам если потребуется.

7. Бояться задать вопрос еще раз

Смотри пункт выше.

8. Слепо верить ТЗ

Что значит: баги документации (логические несоответствия, противоречия, недоработки и т.п.).

К чему приводит: откладывается релиз, блокеры и криты в проде и т.п.

Как увидеть и бороться: про то, как тестировать ТЗ поговорим в следующих постах, поэтому подписывайся и обсудим.

9. Тестировать в перчатках

Что значит: не оставлять комментариев, артефактов после закрытия тикетов.

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

Как увидеть: после закрытия тикета или перевода в протестирован пробежаться по своим комментариям. Если их нет, то нужно оставить.

Как бороться: если есть возможность в баг-трекинговой системе настроить запрос обязательного комментария при закрытии тикета.

10. Использовать только исследовательское тестирование

Что значит: не применять другие техники тестирования.

К чему приводит: пропуск багов, которые быстро и просто находятся другими техниками, например, с помощью таблицы принятия решения.

Как увидеть: при тестировании изучаешь продукт, т.е. нет четких кейсов с ожидаемым результатом.

Как бороться: использовать подходящие техники, о которых поговорим в других постах (подписывайся и не пропустишь).

Почему начал?

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

На тему нужно ли уметь кодить тестировщику, и будут ли тестировщики неумеющие кодить в будущем, круто обсудили в подкасте QAk-QAk и в продакшен.

Как начал?

Мне повезло, у нас на проекте есть инфраструктура на python (что тоже везение - низкий порог вхождения) помогающая команде в работе. Например, есть куча ботов пингующий на разные события (завели баг, надо оценить баг, инвайты начать релиз и т.п.). Этот проект нужно было поддерживать после ухода одного замечательного коллеги (Ваня, если читаешь это, то спасибо за онбординг ;). Коллега ушел, а мы с проектом остались дальше делать жизнь приятней.

Начал с самых простых задач:

• поправить пару строк код,
• обновить записи в БД,
• почитать логи и понять почему падаем.

Этот период можно назвать знакомством с кодовой базой и осознанием, что ничего не знаешь! Тут важно иметь поддержку. Мне казалось, что я никакой ценности не приношу, но руководители всегда подсвечивали важность (Таня, Дима <3) и что прогресс есть. Самую мощную поддержку оказывал автор инфраструктурного проекта (Ерке, ты лучший!). Объяснял архитектуру, показывал как оптимизировать код, как деплоить и откатывать в случае фэйла (да-да, один раз слегка положил прод), по любому вопросу можно было пойти к нему и даже созвониться (это очень круто, потому что он техлид и времени у него оооочень мало).

Дальше задачи стали сложнее:

• написать новую логику в старый функционал,
• реализовать простые фичи

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

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

Чему научился?

Выше уже немного рассказал, но теперь по пунктам:

1. Никогда не лезьте в продовую базу. Как вы поняли я и тут успел чуть нафакапить. Перезаписал одну строчку код, а это могло лишить нужных уведомлений команду. Но к моему счастью сразу это заметил и ментор помог быстро решить.
2. Все факапят и начинают с простого топорного написания кода. Чтобы понимать, где нахожусь при выполнении кода или при дебаге, обкладывал чуть ли не каждый шаг простыми print(smth). Мне казалось, что такое стыдно показывать даже когда задаешь вопросы ментору по зуму, но он меня успокоил сказав, что даже самые топовые разрабы так начинают. А еще его спокойствие и поддержка в случае факапа придавало уверенности. Кстати, и команда относилась с пониманием, если что-то ломалось и правилось не так быстро, как хотелось бы.
3. Никогда не давайте писать тесты разработчику. Это понял немного косвенно, потому что когда ты пишешь код, ты не думаешь "а что если так", твой основной вектор "как сделать чтобы так". Из этого можно сделать вывод, еще раз подтвердить майндсет тестировщиков, что тесты лучше писать тестировщикам (оставив юнит-тесты разработке).
4. У разработчиков много инструментов, которые пригодятся тестированию. Почаще общайтесь с разработкой и узнаете много разных плагинов для командной оболочки или IDE, какие утилиты использовать для написания скриптов или как мокать гео на iPhone.
5. Начинаешь лучше понимать, когда автоматизация не нужна. Только начав писать код понимаешь, что часто автоматизация это не единственное решение, и часто, не самое верное. По другом смотришь на построение процессов, т.е. анализируешь и понимаешь, что дешевле, быстрее и правильней описать флоу, чем долго кодить и не решить проблему. Надеюсь смог передать мысль :)

Пока это все. Но я продолжаю кодить, а значит еще будут посты про влияние кодинга на жизнь тестировщика. Лайки, подписка, репосты приветствуются :)

1. Нет текста у ссылок

Как известно тег <a> задает ссылку на другую страницу или в качестве навигации в рамках одной страницы. Но иногда разработчики используют тег для других целей, и часто опускают текст ссылки. В результате скринридеры не дают понимания что будет если перейти по ссылке. Как понимаете это создает сложности для людей с проблемами зрения Поэтому каждая ссылка должна четко давать понять что будет если по ней перейти.

2. Включение фокуса на лишних элементах

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

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

3. Отсутствует атрибут alt ссылок

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

4. Нет атрибута alt изображений

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

5. Неправильная вложенность списков

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

6. Дублирование label'ов

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

7. Положительные значения для tabindex

Как говорилось в пункте 2 использовать tabindex нужно аккуратно, а самое главное либо 0, либо -1. Почему так мне не совсем понятно, если знаете почему, то дайте знать в комментах. Т.е. задание положительных значений создают проблемы.

8. Некорректный aria-describedby

Атрибут aria-describedby связывает несколько элементов, например, span и input. Т.е. в spane'е можно указать подсказу для input'а, а атрибут aria-describedby свяжет их, и при озвучке будет прочтение spana'а для заданно инпута. Пример:

<label for="psw">Пароль</label>
<input
type="password"
name="password"
id="psw"
aria-describedby="hint"
>
<span id="hint">Пароль должен содержать не меньше 20 знаков</span>

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

9. Нет подписей для кнопок

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

10. Некорректный aria-labelledby

Похожий атрибут, как в пункте 8, но его фишка в том, что он ссылается на другой элемент на стр.

Полезные ссылки

1. Статья в оригинале https://www.tpgi.com/the-top-accessibility-errors-found-in-2023/
2. Доступность простым языком https://doka.guide/a11y/

1. Открытие страницы восстановления пароля по клику на ссылку "Забыли пароль".
2. На странице восстановления есть необходимый элементы для восстановления: поле ввода эл, почты/телефон/логин/etc, кнопка "Отправить/Восстановить/etc". Отмечу отдельно, что телефон и почта должны проверяться по маске, т.е. почта не может быть без @ или телефон должен быть с кодом, определенной длины и т.п.
3. Кнопка "Отправить/Восстановить" доступна после ввода всех обязательных полей. Если не заблокирована при пустых полях, то нужно показывать ошибку "Заполните поля", если нажали "Отправить" с пустыми полями.
4. Кнопка "Отправить" недоступна для многократного нажатия. Если доступна, то не должны слать запросы на сервер на каждый клик.
5. Проверка существования профиля для которого пытаемся восстановить пароль. Если профиля нет, то должны показать соответствующее сообщение. Опционально можно показать предложение создать профиль.
6. Ограничение на количество попыток восстановить. Зависит от конкретных требования, но как минимум стоит хранить куку, в которой будет таймер через какое время можно повторить запрос.
7. Получение на почту письмо с инструкцией восстановления. Также восстановление может быть по sms-коду. Убедиться, что нельзя восстановить неверным или устаревшим sms-кодом.
8. Убедиться в том, что ссылка на восстановление пароля перестает действовать через заданный период времени.
9. Переход по ссылке из инструкции ведет на форму задания нового пароля. По правилам хорошего тона на странице должны быть поля: новый пароль, подтверждение нового пароля. Само собой кнопка "Отправить/Сохранить/etc.".
10. Новый пароль не должен соответствовать старому. Это необязательное правило, но это хорошая практика.
11. Показ сообщения об успешной смене пароля. Если новый пароль и подтверждение пароля не соответствуют сообщать об этом.
12. Открытие формы восстановления, отправка ссылки на восстановления пароля не сбрасывает текущий.
13. Нельзя войти по старому паролю.
14. Можно войти по новому паролю.

Cтатью хорошо дополнят

• Чек-лист: личные данные
• Чек-лист: оплата
• Чек-лист тестирования веб-сайта

Свои проверки, которые я мог упустить - оставляйте в комментариях

• Валидация разметки. От корректности HTML-разметки зависит правильное отображение сайта, индексация в поисковых системах. Проверить можно тут: https://validator.w3.org/
• Скорость загрузки. Важный показатель который можно померить разными способами, например, через https://pagespeed.web.dev или DevTools > LightHouse.
• Сканирование на наличие уязвимостей. В крупных компаниях этим занимается отдел безопасности (слышал от знакомой, что у них этих ребят называют - Безосами). Но проверить на базовом уровне: открытие сайта через https, не указан ли хост в блек-листах и т.п. можно с помощью онлайн утилит. Вот 13 популярных.
• Адаптивность сайта. Желательно посмотреть на реальных устройствах ПК, планшет, смартфон и т.п. Но можно воспользоваться BrowserStack.
• Соответствие UI гайдам. Задача тестировщика сравнить реализацию с гайдами, но все таки рекомендую почитать парочку постов по UI стандартам, чтобы обеспечить удобство и качество графического интервейса. Например, Material Design или UI design principles: guidelines.
• Проверка на кроссбраузерность. Популярность браузеров можно посмотреть на statcounter для всех платформ.
• Функциональное тестирование. Если ты на этапе ознакомления с ТЗ, то почитай "чек-лист тестирования ТЗ".
• Интеграционное тестирование. Проверка API, подключение библиотек, метрик, отображение в гибридном мобильном приложении и т.п.
• Проверка логов на наличие ошибок, предупреждений и информационны сообщений. Можно посмотреть в devTools, в логах сервера.
• Нагрузочное/стресс - тестирование. Обычном этим занимаются специально обученные тестировщики, но ты можешь подписаться на канал и скоро мы научимся это делать!

Статью хорошо дополнят

• Чек-лист тестирования: форма авторизации
• Чек-лист тестирования: личные данные
• Чек-лист тестирования: оплата

Примеры лендингов:

• https://yandex.ru/alice/station-gen2
• https://www.apple.com/macbook-pro-13/

Как работает лендинг

• Пользователь попадает на посадочную страницу через рекламу, прямую ссылку и т.п.
• Пользователь жмет на кнопку "Оставить заявку", "Купить товар" и т.п.
• Попадает на форму заполнения личных данных. Может включать в себя сбор информации по услуге или продукту, которые ищет пользователь. Например, пользователь делится информацией о квартире с клининговой компанией.
• Заполняет форму или отказывается и уходит. Отказ это сигнал, что нужно искать проблему отказа от услуги или товара.
• Сохранение данных от клиента.
• Связь с клиентом.

Чтобы быть честным, нужно сказать что есть лендинги, которые работают иначе. Таких страниц много. Например, Squeeze Page предназначены для сбора адресов эл. почты у пользователей, а после на эти адреса рассылаются рекламные письма. Или страница "404 - страницы не найдена" может также служить для сбора данных или пожеланий потенциального покупателя.

Но в целом суть одна: говорим что мы можем дать посетителю то, чего он желает взамен на его персональные данные.

Чек-лист тестирования

Это общий чек-лист. Что-то может быть актуальным, а что-то можешь предложить, как фичреквест. Погнали:

1. Техническое задание и визуальные гайды. В первую очередь идем по требованиям. Вот чек-лист тестирования тех. задания. Тут найдешь полезные расширения для веб-тестирования. А тут можно почитать про тестирование веб-сайтов в целом.
2. Кроссбраузерность. Проверяем, что страница отображается и функционирует как ожидается на всех популярных браузерах.
3. Адаптивность. Проверяем, что лендинг отображается корректно на разных размерах экранов и на разных платформах: ПК, смартфон, планшет. Особенно отмечу проверку изменения ориентации на телефоне.
4. Якоря. Логические блоки должны отображаться по прямой ссылке. Например, URL#contacts ведет к блоку "Контакты", а URL#specialists к блоку с мастерами сервиса.
5. Поп-ап. Часто заявки собираются в сплывающих окнах. Нужно проверить, что они появляются, корректно отображаются на разных экранах, корректно отрабатывают нажатия. Часто бывает, что один и тот же поп-ап, вызванный из разных логических блоков, ведет себя по-разному (где-то не работает кнопка отправки заявки, где-то поп-ап появляется под картинками и т.п.)
6. UTM-метка. Проверить, что в URL зашивается информация о пользователе. Например, твой сайт santehnik.org. Пользователь нашел сайт через выдачу яндекса. В настройках яндекс директа задали рекламную кампанию "Новогодняя акция 2022", и тогда ссылка будет иметь вид: santehnik.org?utm_campaign=new_year_sale. В итоге после парсинга UTM-меток, можно узнать больше информации о своих потенциальных клиентах, в том числе о том что переход был по акции.
7. Полям ввода задан атрибут autocomplete. Этот атрибут помогает браузерам правильно идентифицировать поле и помочь пользователю его быстро заполнить из сохраненных персональных данных. Например, если у поля autocomplete="email", то браузер предложит подставить в него сохраненную почту.
8. Телефонные ссылки, почтовый агент, мессенджеры. Убедиться, что для телефона и почты использованы ссылки tel и mailto соответственно. Для мессенджеров указаны корректные аккаунты.
9. Заказ услуги/товара или обратная связь. Тут нужно проверять 2 части: фронт и бэк. Если обобщить то, на фронте валидацию вводимых данных (пустые поля, формат телефона и почты и т.п.) и уведомление в духе "Мы получили ваше обращение и свяжемся с вами через...", на бэке добавление заявки в базу данных (корректность отображения текста, не должно быть кракозябров, указание таймзоны клиента и т.д.), проброс в CRM и т.п.
10. Куки. Проверить, что в куках запоминаем выбор языка или региона пользователя и т.п.
11. Минификация. Важно сжать все что можно: картинки, css-стили, js-скрипты. Это нужно для того, чтобы лендинг загружался быстрее. Почитать можно, например, про минификацию css-стилей.
12. Ошибки в консоли. Параллельно с проверкой кликабельности, скроллинга или отправки данных на сервер, открой dev-tools (вкладка console) и смотри в консоль. Часто можно увидеть js-ошибки. Еще можно поглядывать на вкладку Networks, там найдешь проблемы с сетевыми запросами.
13. Смена языка, региона, шрифта, цветовой темы и т.п. Советую проверить с очисткой кэша при рефреше страницы. При обновлении настройки не должны слетать, потому что прописываются в куках.
14. Подключение скриптов, шрифтов, стилей и картинок. Проверить, что в html-разметке есть их подключение, что в сетевых запросах все ресурсы успешно загружены. И очень критично проверить, что подключены скрипты аналитики (яндекс метрика, гугл аналитика и т.д.).
15. SEO-теги. Это в зоне ответственности seo-шников, но мы то ответственные ребята и хотя бы одним глазом глянем. Например, важно в html-разметке указать тег meta с атрибутом name="description" являющейся аннотацией сайта, которая отображается в поисковой выдаче. Почитай тут про сео-теги.
16. Поиск битых ссылок. Также в зоне seo-шников, но проверить ссылки на лендинге прокликав их - несложно. Редко их бывает много.
17. Проверка переходов. Если на сайте есть переходы на блоки, анимация и прочие бродилки, то нужно убедиться, что все они доступны и имеют ожидаемые переходы.
18. Многократные нажатия на кнопку отправки. Очень важно проверить, что клики на кнопку "Отправить заявку" не посылает кучу запросов без завершения предыдущих. Самое лучшее решение блокировать кнопку после клика и до выполнения запроса.
19. Убедиться, что переключились на продовый сервер. Нередко бывает, что во время разработки и тестирования лендинг отсылает заявки на тестовый сервер, а после раскатки в прод забывают переключить сбор заявок на прод.
20. Перфоманс тестирование. Чаще всего проводят для лендингов крупных сервисов, куда потенциально может заходить миллионы пользователей.

Полезные ссылки

1. Полезные веб-сервисы для тестировщика
2. The 13 Types of Landing Pages & How to Pick One for a Campaign
3. Как использовать ссылки телефона и почты
4. HTML attribute: autocomplete
5. UTM-метки: зачем они нужны и как их настроить
6. Какие HTML-элементы более востребованы: анализ 8 млн страниц с позиции SEO
7. Узнать у google, как оптимизировать сайт
8. Проверить оптимизирован ли сайт под отображение на разных устройствах

1. Допустимые символы логина и пароля. Определяется требованиями ТЗ. Совет: учитывай язык пользователя, т.е. используемую кодировку.
2. Минимальная, максимальная длина логина/пароля.
3. Регистрочувствительность. Также определяется ТЗ, но советую уточнить у менеджера проекта, если про это не сказано. Логин может быть не чувствителен, а вот пароль в 99% случаев чувствительный.
4. Обязательность ввода. Поля логин и пароль в 99% должны быть заполнены. Проверка сводится к тому, что пользователь должен увидеть уведомление о том, что поля обязательны к заполнению после клика "Войти" или после смены фокуса с поля пароль/логин.
5. Авторизация валидными данными. Проверяй разную комбинации: телефон/пароль, почта/пароль, телефон/sms-код (конечно, если есть такие возможности функционала).
6. Многократное нажатие на кнопку "войти". Львиная доля форм просто блокирует кнопку до ответа сервера.
7. Авторизация НЕвалидными данными: пустые поля, одно из полей пустое, в одном из полей невалидные данные, оба поля с невалидными данными. Для кейсов с невалидными данными ошибка выводится только после клика "Войти". Для генерации тестовых данных похожих на реальные советую использовать сервис Mockaroo (больше полезных сервисов в посте "Полезные веб-сервисы для тестировщика")
8. Ввод пробела и невидимых символов. Часто срабатывает ошибка валидации, если в конце или в начале ввода email'a (часто используется, как логин) ввести пробел или перевод каретки '\n'.
9. Демонстрация ошибки, при вводе некорректных данных. Показываем как после клика "Войти", так и если, например, пользователь вводит невалидные данные, превышает количество символов и т.п.
10. Корректные атрибуты HTML-тегов для логина/пароля. Самый главный атрибут "required" (подробнее на htmlbook.ru).И конечно же у парольного поля должен быть атрибут type = "password" (подробнее на mdn). Особенно актуально для веб-сайтов и гибридных приложений (подробнее "Особенности мобильного тестирования").
11. Сокрытие/показ вводимого пароля. По умолчанию скрыт (показываем точки), по нажатию на иконку глаза показываем. Если это форма создания учетки, то на форме будет еще поле "подтверждение введенного пароля". Часто по клику на иконку глаза в одном поле, нет реакции в другом.
12. Восстановление пароля всеми доступными способами (звонок, sms, код на email, пуш в приложение). Редкий кейс, но пару раз встречал, что можно перейти к форме восстановления пароля по старому проверочному коду из sms. Советую проверять это!
13. Смена пароля, логина. Логин меняется редко и точно в настройках профиля. Пароль можно сменить, как минимум через форму восстановления доступа или через настройки профиля.
14. Авторизация под старыми данными. Стоит проверить сразу после смены пароля или логин. Бывает так, что обновленные данные не доехали до всех баз или есть проблемы с кэширование и т.п.
15. Двухфакторная аутентификация (2FA) и авторизация по соц. сетям. В 2FA тщательно стоит проверить восстановление доступа (по сгенерированным кодам, по резервной почте и т.п.).
16. Безопасность пароля. Если нужно проверить качество принимаемых паролей, то советую использовать сервис касперского.
17. Демонстарция подсказок при попытки создать невалидный пароль, логин. Часто бывает, что подсказки не скрываются после ввода корректных данных. Обращай внимание.
18. Бан через N-попыток входа или смены пароля. Можно отправлять уведомление на почту, телефон, что кто-то пытается войти. По-хорошему это делается даже при первой валидной авторизации. И еще стоит обратить внимание, что в уведомлении должно быть понятно описано, что делать, если входишь не ты. Плюс проверь, что ссылки в уведомлении не битые, иначе это будет провал!
19. Вставка текста в поля. Есть разные мнения насчет вставки пароля. Ко считает нормальным, а кто-то нет. Смотри в ТЗ. Проверяй как хоткеи (ctrl+v), так и вызов контекстного меню мышкой.
20. UI полей и формы. Об этом будем говорить отдельно (поэтому подписывайся на телеграм канал).Но помни, у тебя есть графические макеты для сравнения, а если нет, то общепринятые гайды, например, для устройств Apple "Human Interface Guidelines".
21. HTML, XSS, SQL - инъекции. Об этом можешь почитать на хабре:

• Подробное руководство по HTML-инъекциям [хабр]
• Что такое XSS-уязвимость и как тестировщику не пропустить ее [хабр]
• Первое знакомство с SQL-инъекциями [хабр]

В чек-листе идет речь блокерные проверки и требования. Если есть что добавить, то пиши в комментариях, не пропустим баги вместе :)

• Заведи тестовую почту. При тестировании форм с личными данными, в большинстве случаев, получаешь отбивку на почту с введенной информацией. Например, оформил покупку билета на самолет - получил отбивку на почту. Важно: никогда не используй личную почту!
• Заполняй формы с помощью автоподстановки. Особенно актуально для тестировщиков веб-сайтов. Сохраняешь несколько профилей личных данных в браузер и подставляешь одним кликом. Экономия времени.
• Подготовь пул профилей. Чтобы не придумывать постоянно и учитывать разные форматы данных. Хранить можно от excel-таблицы до SQL-баз.
• Подготовь профили на разных языках (проверка кодировки). Например, проверить ввод на арабском языке (ввод справа налево), китайские иероглифы и т.п.
• Ограничения по количеству символов и типу ввода. Ограничения задаются ТЗ, например, поле ввода "Рост" принимает только целое числовое значение. Также требования задаются нормативными документами, например, ГОСТом: длина номера и серии паспорта X символов и т.п.
• Формат данных. Например, номер телефона может быть с префиксом +7, 8 или вообще без префикса. Сюда же относятся кейсы с ФИО (указание полностью, только фамилия и имя, фамилия и инициалы), с датой рождения (ММ.ДД.ГГГГ, MM-DD-YYYY и т.п.).
• Формат адресов. В 80% случаев формы с личными данными имеют поля ввода адреса. И тут много кейсов: адрес разбит на сущности (улица, дома, домофон и т.д.), только город или улица и т.п. Важно учесть, что в разных странах форматы могут отличаться значительно
• Корректность сохранения. В рамках одного профиля не должно быть 2 значений "Пол", "Дата рождения". Не должно быть дубликатов профилей и т.п.
• Данные введенные пользователем вручную приоритетней тех, что можно подставить из сохраненного профиля.
• Личные данные должны храниться, передаваться безопасно. Передача строго по https-протоколу, профили должны быть заблокированны паролем, мастер-паролем и т.п.

Поддержи выход новых постов лайком, подпиской и комментарием 😉