Привет, это Наташа из SmartHead!
Как начать работу над проектом, написать тестовую документацию, понять, когда и как переходить к автоматизации… и выжить?
Работа QA всегда связана с множеством документации — изучить логику приложения, код разработчиков, написать тест-план, тест-кейсы, репорты, отчёты — и так по кругу... Часто это утомляет и мне, как ленивому человеку и QA, хочется ускорить и автоматизировать все, что сделает мою (а возможно и вашу) работу легче и приятнее.
Поэтому в этой серии статей я разберу, как быстрее вникать в новый проект, писать тестовую документацию, а также поделюсь полезными промптами для ChatGPT, которые использую сама. Расскажу, как применять ИИ, чтобы облегчить работу и не тратить время на рутину.
Кому будет полезно
Начинающим QA — разобраться в проекте без лишнего хаоса
Опытным QA — использовать как чек-лист, чтобы не упустить важные моменты
Тимлидам — удобно и легко вводить новых сотрудников в команду
Первая часть поможет
быстро адаптироваться на новом проекте;
разобраться в документации (или при ее отсутствии);
научиться эффективно использовать ChatGPT(LLM) в работе
С чего начать: доступы, чаты, вопросы
Первое, что необходимо сделать, начиная работу над новым проектом — получить доступ ко всем ключевым системам, чтобы было актуально использовать последующие пункты.
Мини-чек-лист по необходимым доступам:
Staging/dev/prod-окружения
Репозиторий кода (GitHub, GitLab, Bitbucket)
Баг-трекинг (JIRA, YouTrack, Trello)
Система управления тестированием (TestRail, Qase, Xray)
Тестовые аккаунты (с разными ролями, правами)
API-доступы и токены (Postman, Swagger, GraphQL)
Доступы к базам данных (SQL, DBeaver, pgAdmin)
Логирование и мониторинг (Sentry, Kibana, Grafana)
Рабочие чаты
Потратить время в начале проекта на получение доступа стоит хотя бы для того, чтобы не попасть в ситуацию:
BTW
В статье Качество на каждом уровне: мой подход к роли QA я уже говорила как важна командная работа, но сейчас хотелось бы сконцентрироваться на том как команда может помочь QA влиться в работу.
С кем и о чем говорить?
Кто | Когда и зачем идти |
Лиды / Менеджеры | Если непонятно, с чего начать, нет доступов, неясны приоритеты, ты не уверен(а), кто отвечает за модуль/направление. Также они чаще всего могут дать общее представление о продукте и команде. |
Разработчики | Когда нужно разобраться в архитектуре, уточнить, как работает конкретный модуль, воспроизвести баг, протестировать новую фичу или понять, почему в логах ошибка. |
Бизнес-аналитики / Продукт-менеджеры | Если нужно понять бизнес-логику, узнать, какие сценарии критичны, какие баги реально мешают пользователям. Можно узнать приоритеты, поведение системы в нестандартных ситуациях, критерии приемки. |
DevOps / разработчики (опционально) | Если надо настроить окружение, доступы, CI/CD пайплайн, логи, прокси, подключить мониторинг или разобраться, почему что-то не деплоится или не тестируется. |
Другие QA | Уточни, как они пишут кейсы, как репортят баги, на что обращают внимание, какие есть неформальные договоренности. |
Несколько важных замечаний:
Все будет зависеть от команды — адресаты вопросов могут меняться.
Перед тем, как задавать вопросы лучше попытаться самостоятельно разобраться, поискав ответы в документации, коде и гугле. В ходе этого часть вопросов может отвалиться.
По оставшимся вопросам стоит составить список с примерами и четким описанием вопроса. Так можно будет гораздо быстрее получить ответ и не тратить время на выяснение, что именно тебе непонятно.
Как разобраться в документации (даже если её нет)
После получения доступов пора разбираться, с чем вообще работать. Появится(скорее всего) 2 варианта:
документация есть (ура),
документации нет (не ура, но разберемся).
Какую документацию следует изучить:
Описание проекта (бизнес-логика, роли, основные процессы)
API-документация (эндпоинты, ответы, сценарии)
Тестовая документация (кейсы, планы, подходы)
История багов (частые ошибки, слабые места)
CI/CD (где запускаются тесты, как настроен пайплайн)
Мониторинг и логирование (где и как искать ошибки)
Если информации нет или она неполная
Иногда может быть такое, что документация вроде бы есть, но:
Описание проекта — один абзац «мы делаем крутое приложение».
Архитектура нигде не описана.
Нет понимания ролей и прав пользователей.
Тест-кейсы устарели на два релиза назад.
API — просто список эндпоинтов без логики — кто и когда их вызывает.
И главное — никто не может сказать, что здесь вообще происходит.
Что делать, если нет:
- описания проекта (бизнес-логика, роли, процессы)
Пройти сквозной пользовательский сценарий — регистрация, вход, действия в системе.
Отследить, какие есть роли (гость, юзер, админ) — по UI, правам доступа, API.
Составить свою карту системы: какие сущности есть, как они связаны, что делают. Нарисовать в Miro, FigJam, на салфетке — главное, чтобы стало понятно.
- API-документации
Открыть DevTools → вкладка Network — смотреть, что летит при действиях в UI.
Закидывать запросы в Postman или Swagger, если есть.
- тестовой документации
Найти старые кейсы и/или автотесты.
Пройти основные сценарии вручную и составить свой чек-лист.
Использовать ChatGPT для анализа на уязвимые места.
- истории багов
Заглянуть в баг-трекер (если есть) и посмотреть закрытые тикеты.
Пообщаться с командой: разработчики и QA могут рассказать какие модули доставляли больше всего проблем.
- информации по CI/CD
Поговорить с разработкой: где крутятся тесты, кто их запускает.
Заглянуть в .gitlab-ci.yml, .github/workflows, Jenkins pipeline.
- информации по логированию и мониторингу
Уточнить наличие Sentry, Kibana, Grafana.
Смотреть наличие ошибок в консоли и Network в DevTools браузера.
Следить за логами в консоли, лог-файлах, браузере при работе локально.
Как можно заметить, даже с нулевой документацией есть пути выстроить работу и разобраться в проекте. Главное — не пытаться «разобраться во всём» сразу. Достаточно начать.
ChatGPT в помощь: как получать полезные ответы
Когда я только начала пользоваться ChatGPT, было сложно сообразить как и в чем он может помочь, но после некоторой практики я стала лучше понимать как получать от него полезные, четкие и подробные ответы. Благодаря этому получается снять часть нагрузки в рутиных делах и переключиться на более интересные.
Хоть не всегда можно добиться идеального ответа, но есть несколько заметок, которые помогают мне получить ожидаемый результат.
Как формулировать промпты
1. Назначай роль
Хорошо: Ты — опытный QA-инженер, специализирующийся на автоматизации тестирования. Подскажи, какие инструменты лучше использовать для UI-тестов.
Плохо: Расскажи про тестирование.
2. Структурируй запрос
Разбей вопрос по пунктам — так будет меньше воды и больше конкретики в ответе:
1. Какие техники тестирования бывают?
2. Когда использовать каждую из них?
3. Какие инструменты подходят для автоматизации?
3. Давай информацию порционно
Если скинуть огромный кусок текста (например, всю документацию), ChatGPT, скорее всего, что-то упустит и/или даст поверхностный ответ. Лучше разделить доку по модулям или логическим блокам — и загружать частями.
4. Не мешай темы
Один запрос = одна тема. Не стоит одновременно спрашивать про API, UI и базу данных. Ответ будет либо размазан, либо модель «зацепится» только за одну часть. Оптимально — разбить на отдельные вопросы.
Напоследок
Мини-гайд: как использовать ChatGPT для анализа документации
Промпт для ChatGPT: быстрое изучение документации
Ты — опытный QA. Проанализируй документацию проекта и помоги составить основу для тестирования: тест-план, чек-листы и кейсы.
Документация: (вставь сюда текст, ссылку или описание)
Что нужно получить:
Список ключевых модулей системы, которые надо тестировать.
Основные пользовательские сценарии (коротко, по шагам: что делает пользователь, как реагирует система).
Зоны риска: что может ломаться, где есть технические ограничения или уязвимости.
Важные API-эндпоинты и UI-элементы, требующие особого внимания.
Что не описано в документации — список вопросов к команде.
Архитектурные или технические зависимости, которые важно учитывать.
Формат: Структурированный список с заголовками. Без общих описаний и вступлений — только суть.
Как использовать ответ?
Функциональные модули → структура тест-плана:
что тестируем;
какие методы;
какие инструменты;
риски и ограничения.
Пользовательские сценарии, описание API,UI, зависимости → чек-листы, тест-кейсы.
Проблемные зоны, критичные точки → основа для глубокой проработки тест-кейсов.
Вопросы → обсуждения с командой.
ChatGPT не заменит опыт и здравый смысл, но если правильно его использовать — он может стать подручным в рутинных и подготовительных задачах. Главное — научиться задавать вопросы правильно.
Короче говоря
Если не получить доступы, не разобраться в продукте и не наладить коммуникацию — баг в проде становится вопросом времени. А баг в проде ведет к плохому настроению, постоянное плохое настроение к выгоранию, выгорание к багу в проде, баг в проде к…. короче, вы поняли)
Чтобы этого избежать используйте новые технологии и возможности для сокращения рутинных задач, чтобы заниматься тем, что не может (пока) сделать AI и тем, что вам действительно нравится!
Важно выстроить структуру с самого начала и подобрать подход, позволяющий быть вам хардер, беттер, фастер, стронгер!
В следующей части разберем организацию тестирования, написание тест-плана и тест-кейсов(тоже с ChatGPT).
