Середина июля, у нас в разгаре функциональное тестирование глобального обновления. Тестирование на внутренних стендах уже завершено, теперь заказчик тестирует на своём тестовом стенде. Каждый день они присылают замечания, которые нужно оперативно обрабатывать.
Утром на дейли распределили замечания между тестировщиками — сегодня немного, всего 6. Беру первое замечание в работу. Моя задача — понять, является ли оно дефектом, и если да, то завести баг-репорт и передать разработчикам.
Читаю описание кейса от клиента, смотрю его скриншоты (**спасибо, что скриншоты, а не фото экрана**). Да, такой кейс был, и, как мне помнится, его проверяла я. Перечитываю описание несколько раз, чтобы убедиться, что их ожидания соответствуют согласованным требованиям. Всё верно, соответствует.
Изучаю скриншоты: на экранной форме видны лишние кнопки, которых в этом кейсе быть не должно. Очень странно, ведь я точно это проверяла... Ищу задачу на эту доработку. Пока ищу, начинаю сомневаться: может, мне это приснилось и я не проверяла это? Нашла — да, точно проверяла, вот и мои скрины есть. Кнопок не было. Это было неделю назад. Может, что-то успели сломать?
Иду на наш стенд, воспроизвожу кейс. Пока воспроизвожу, вспоминаю условия: наличие кнопок зависит от одного атрибута сущности в базе данных... Хм, может, у них не проставлен этот атрибут?
Воспроизвожу кейс с атрибутом на нашем внутреннем стенде — все кнопки отображаются корректно, лишних нет. Сбрасываю кэш — кнопки по-прежнему на месте, лишних нет.
Захожу в DevTools, проверяю, что атрибут возвращается на фронтенд с запросом корректно. Запрашиваю данные из базы данных клиентского стенда — атрибут есть, но лишние кнопки всё ещё отображаются. Странно, очень странно... Надо подумать.
Встаю из-за компьютера и иду делать кофе. Параллельно обдумываю, что ещё можно проверить. Возвращаюсь к работе и решаю написать разработчику:
— Маш, привет! Подскажи, по каким условиям рисуются вот эти кнопки на форме? (прикрепляю скрин с лишними кнопками)
Маша — наш фронтенд-разработчик. Жду её ответа. Через некоторое время она отвечает:
— Привет! Зависит от этого атрибута. (скидывает скриншот DevTools с запросом, где в ответе выделено... не то поле из БД, которое я проверяла, а какое-то `descriptionValue`...)
Я в шоке. Что??? Почему?? Как? В ТЗ чётко указано, что условие — этот атрибут, который заполняется на бэкенде и может принимать только определённые значения (enum). А фронтенд просто игнорирует его и проверяет какое-то `description` — текстовое поле, заполняемое пользователями!
Ну как так можно? Даже мне, не разработчику, очевидно, что нельзя привязывать логику к полю под названием «описание»! Это же просто текст, там могут быть любые значения...
Если ты, как разработчик, не уверен, на какое поле вешать логику, ну спроси хотя бы у коллег! Это же джуниорская ошибка! И вопросы к ревью: как это пропустили? Даже не зная контекста задачи, ревьюера должно было насторожить, что логика завязана на конкретных значениях поля `description`.
Признаюсь, при тестировании я не учла, что разработчик мог так реализовать. Сам атрибут не новый, на наших стендах `description` созданы давно и их никто не трогает. Видимо, они случайно совпадали со значениями нужного атрибута, и фронтенд решил использовать их. Конечно, я не пробовала менять `description` при тестировании — там много данных, и все варианты не проверишь...
Но вернёмся к кейсу. Теперь ясно: на стенде заказчика `description` заполнен иначе, поэтому проверка не срабатывает и появляются лишние кнопки. На всякий случай запрашиваю данные из БД заказчика — так и есть! Дефект локализован. Бинго!
Завожу баг-репорт, ставлю приоритет, передаю разработчику. Ещё раз обсуждаю с фронтендом, какое поле использовать для фикса. В баг-репорте подробно описываю проблему и даю инструкции по тестированию (на случай, если проверять буду не я): обязательно проверить с разными значениями `description` и целевого атрибута.
Выводы для себя: в будущем нужно учитывать подобные сценарии при тестировании.
Чувствую удовлетворение от проделанной работы: оперативно разобралась в проблеме, локализовала дефект, предложила решение на уровне кода. И всё это без доступа к коду и без знания JavaScript!
Такие разборы помогают глубже погрузиться в продукт, прокачать навыки локализации дефектов, понять важность данных на стендах и увидеть пробелы в тестировании. В следующий раз в подобной ситуации я разберусь гораздо быстрее.