Ответ
В такой ситуации QA-инженер должен самостоятельно выявить ожидаемое поведение системы и структурировать процесс тестирования.
План действий:
- Исследование продукта: Изучить интерфейс (UI) и API через документацию, если она есть, или методом "черного ящика". Цель — понять основной функционал и пользовательские потоки.
- Коммуникация с командой: Провести уточняющие встречи с разработчиками, аналитиками или продакт-менеджером, чтобы зафиксировать их видение работы фичи.
- Создание артефактов: На основе полученной информации составить чек-листы, mind maps или простые сценарии использования (user stories).
- Применение техник тестирования: Использовать стандартные подходы:
- Тестирование на основе рисков: Сфокусироваться на наиболее критичных для бизнеса сценариях.
- Эвристики: Проверить основные операции CRUD (Create, Read, Update, Delete), граничные значения, совместимость.
- Исследовательское тестирование: Систематически изучать приложение, документируя находки.
- Документирование и согласование: Все предположения и выявленные сценарии фиксировать и согласовывать с заинтересованными сторонами. Это превращает неформальные требования в основу для будущих тестов.
Пример автотеста для проверки базового состояния страницы логина:
def test_login_page_default_state():
"""Проверяет наличие обязательных элементов на странице логина при её открытии."""
page = open_login_page()
assert page.username_field.is_displayed(), "Поле для логина отсутствует"
assert page.password_field.is_displayed(), "Поле для пароля отсутствует"
assert page.submit_button.is_displayed(), "Кнопка отправки формы отсутствует"
assert not page.error_message.is_present(), "Сообщение об ошибке не должно отображаться изначально"Ключевой итог — превратить отсутствие требований в возможность проявить проактивность и заложить основу для качественного тестового покрытия.
Ответ 18+ 🔞
А, ну это же классика, блядь! Ситуация, когда от тебя хотят магию, а на входе дают нихуя. Типа «вот фича, она где-то там, в тумане, а ты, QA-инженер, иди и разберись, как оно должно работать, ёпта». Знакомо до боли, в рот меня чих-пых.
Ладно, не будем ныть, как баба на сенокосе. Берём ситуацию в свои ебальники и действуем по плану, который не подведёт, даже если требования написаны на салфетке в сортире.
План, блядь, действий, чтобы не быть распиздяем:
-
Лезем в продукт, как в карман за последней сигаретой. Нет документации? Да похуй! Берём метод «чёрного ящика» и начинаем тыкать во все кнопки, поля и ссылки. UI, API — всё под прицел. Цель — понять, что эта штука вообще делает и как пользователь должен с ней взаимодействовать. Просто представь себя самым дотошным и тупым юзером на свете.
-
Трёмся к команде, как кошка о ногу. Не стесняйся, блядь! Собирай уточняющие встречи с разработчиками, аналитиками или продактом. Задавай вопросы, пока не станет ясно, что они сами себе представляют под «рабочей фичей». Фиксируй их бред — прости, видение — как мантру. Это потом спасёт от «а я думал, что...».
-
Создаём артефакты, чтобы не забыть. На основе всей этой информации лепим чек-листы, майнд-мапы или хотя бы user stories на коленке. Главное — структурировать этот поток сознания, который у тебя сейчас в голове.
-
Включаем стандартные техники, как на автопилоте. Не надо изобретать велосипед, его уже придумали, блядь.
- Тестируем по рискам: Сначала ломаем то, что больнее всего уронит бизнес, если сломается. Не надо с первого захода проверять, меняется ли цвет кнопки при ховере.
- Юзаем эвристики: CRUD (создай, прочитай, обнови, удали), граничные значения, совместимость — наш хлеб, ёпта.
- Исследуем, как Шерлок Холмс: Системно, но с фантазией. Документируй все находки, даже самые идиотские. «При вводе 1000 символов в поле «Имя» сервер лег и не встаёт» — вот это находка!
-
Всё записываем и всех согласовываем. Все твои догадки, предположения и выявленные сценарии — не в воздух, а в документ. Потом идёшь к заинтересованным лицам и говоришь: «Смотрите, я так понял. Если не так — поправьте, а то будет поздно». Так из воздуха рождается основа для тестов, блядь.
Вот тебе пример кода, который просто проверяет, что страница логина вообще живая и на ней есть всё необходимое. Без изысков:
def test_login_page_default_state():
"""Проверяет наличие обязательных элементов на странице логина при её открытии."""
page = open_login_page()
assert page.username_field.is_displayed(), "Поле для логина отсутствует"
assert page.password_field.is_displayed(), "Поле для пароля отсутствует"
assert page.submit_button.is_displayed(), "Кнопка отправки формы отсутствует"
assert not page.error_message.is_present(), "Сообщение об ошибке не должно отображаться изначально"Итог, сука, простой: отсутствие требований — это не трагедия, а возможность блеснуть проактивностью и заложить, блядь, нормальный фундамент для тестирования. Покажи, что ты не просто кнопки тыкаешь, а думаешь головой. Вот тогда и уважение появится, и качество продукта не будет на уровне плинтуса.