Какие у тебя есть вопросы?

Ответ

  1. Процесс и инструменты: Какие инструменты и фреймворки (например, Selenium, Cypress, Playwright, JUnit/TestNG, Allure) используются для автоматизации тестирования в проекте? Какой стек технологий у продукта?

  2. CI/CD и релизы: Как интегрировано тестирование в CI/CD пайплайн (Jenkins, GitLab CI, GitHub Actions)? Какова частота релизов и кто отвечает за запуск и поддержку автотестов?

  3. Метрики качества: На какие метрики качества команда обращает основное внимание (например, процент покрытия кода тестами, процент падающих/флейки-тестов, время выполнения тестовой сборки)?

  4. Работа с флейки-тестами: Как команда выявляет и борется с флейки-тестами? Есть ли выделенное время на их стабилизацию?

  5. Влияние на процесс: Есть ли у QA-инженеров возможность влиять на процесс разработки на ранних этапах (например, участие в планировании, ревью требований, внедрение практик тест-дизайна)?

  6. Сложности: С какими основными сложностями или "болями" сталкивается команда в текущем процессе тестирования?

  7. Развитие автоматизации: Какие есть планы по развитию автоматизации? Рассматривается ли переход на новые инструменты или подходы (например, тестирование производительности, безопасность, внедрение AI/ML для тестирования)?

  8. Оценка эффективности: Как оценивается эффективность и ROI от автоматизации тестирования в проекте?

  9. Коммуникация: Как организовано взаимодействие между QA, разработчиками, DevOps и менеджментом?

  10. Ожидания: Какие ключевые задачи и ожидания будут у меня, как у нового QA-инженера, в первые 3 месяца работы?

Ответ 18+ 🔞

А, ну это ты про нашу песочницу, где мы песок грызём и в монитор плюём? Отлично, щас всё разложу по полочкам, только присядь, а то рассказ будет долгий, как очередь в поликлинике.

1. Инструменты и стек Ёпта, ну тут у нас классика жанра, как борщ со сметаной. Фронт — React, бэк — Spring Boot (Java, ядрёна вошь, куда ж без неё). Автотесты пишем на Playwright (TypeScript) — он быстрый, стабильный, не то что Selenium, который иногда ведёт себя как пьяный мартышлюшка. Для API-тестов используем REST Assured. Сборка и раннер — Gradle и JUnit 5. Для отчётов — Allure, чтобы красиво было, а то менеджмент любит, когда графики и красивые пикчи, а не просто «всё упало, идите на хуй». Ещё есть Docker, чтобы поднимать тестовое окружение локально, а то без него вообще терпения ноль ебать.

2. CI/CD и релизы Релизы — каждые две недели, как часы, только иногда эти часы бьют по голове. Всё завязано на GitLab CI. Как только делаешь мерж в develop — запускается пайплайн: сборка, юнит-тесты, линтеры, а потом наш слот — E2E-тесты на Playwright. Запускаются в контейнерах, параллельно, чтобы быстрее. Если всё зелёное — артефакт летит дальше, на стейджинг. За поддержку и запуск отвечаем мы, QA, вместе с DevOps-ами. Они за инфраструктуру, мы за логику тестов. Если пайплайн сломался — все бегут как гомосеки налетели, потому что релиз под угрозой.

3. Метрики качества Смотрят в основном на три вещи:

  • Процент успешных прогонов E2E-свиты. Должен быть выше 95%, иначе начинается волнение ебать.
  • Время выполнения полного пайплайна. Стараемся уложиться в 20 минут, иначе разработчики начинают ныть, что «медленно, я не могу мержить».
  • Количество багов, ушедших в прод. Вот за это нам потом в душу мать от прод-менеджера. Стараемся, чтобы было ноль, но иногда проскакивает какая-нибудь хитрая жопа с кэшированием.

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

4. Флейки-тесты О, это наша вечная боль, ёперный театр! Выявляем так: смотрим в Allure на историю прогонов, если тест падает через раз — он наш клиент. Потом подозрение ебать чувствую — начинаем копать: логи, тайминги, состояние базы. Часто виноваты неявные ожидания или грязные данные. Борьба: переписываем с умными ожиданиями, изолируем данные, а если совсем хуй с горы — выносим в отдельную «флейки-группу» и прогоняем её несколько раз. Выделенного времени нет, чиним по факту, когда портят статистику.

5. Влияние на процесс Да, можем влиять, и это овердохуища круто. Мы сидим на планировании, тыкаем пальцем в требования и говорим: «Э, бошка думай, а как это тестировать-то? А где тут валидация?». Часто помогаем писать тест-кейсы ещё до того, как код написан. Разработчики в целом адекватные, прислушиваются, особенно когда показываешь, как их фича накрылась медным тазом при первом же клике.

6. Основные сложности

  • Тестовые данные. Иногда их подготовка — это отдельный квест сложнее, чем написать тест. Ебать колотить, сколько времени уходит.
  • Синхронизация с бэкендом. Иногда API меняется, а нам говорят за день до релиза. Вот тут сам от себя охуеваешь.
  • Поддержка тестов. Фичи плодятся, а старые тесты надо обновлять. Иногда кажется, что мы только этим и занимаемся.

7. Планы по развитию Хотим внедрить тестирование производительности на k6, потому что один раз было так медленно, что удивление пиздец. Ещё смотрим в сторону тест-ранеров для мобилок (у нас есть адаптивная версия). Про AI/ML пока только болтаем на кухне, типа «а вот если бы нейросеть писала тесты...», но до дела не доходит, да похуй, честно говоря.

8. Оценка эффективности (ROI) Считают примерно. Смотрят, сколько багов ловят автотесты до ручного тестирования, и сколько времени экономят на регрессии. Цифры в отчётах красивые, но все понимают, что главный ROI — это когда в пятницу вечером не надо сидеть и вручную проверять 100500 сценариев перед релизом. Вилкой в глаз или в жопу раз — без автоматизации мы бы просто сдохли.

9. Коммуникация Всё в Slack и Jira. Ежедневные стендапы, недельные планирования. С DevOps общаемся, когда пайплайн пизда рулю. С менеджментом — раз в неделю показываем отчёты. В целом, доверия ебать ноль к тикетам без тест-кейсов или непонятных, поэтому всегда уточняем.

10. Ожидания от тебя (первые 3 месяца)

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

Главное — не бздеть задавать вопросы. Лучше выглядеть распиздяем первую неделю, чем потом полгода разгребать последствия своего молчания. Всё ок?

Видео-ответы