Перейти к содержанию

QA-трек

Параллельно с учебным треком стажёр ведёт QA-трек — работу с багами и обратной связью в geotimlab.wiki. Это второй поток Фазы 1, и на гейте он оценивается наравне с кодом проекта защиты.

Цель трека

  • Вход в команду через реальный вклад в продукт (баг-репорты).
  • Погружение в продукт и предметную область. Тестируя боевой стенд, стажёр быстрее понимает, что такое образцы, выработки, испытания, паспорта — и видит, зачем строит свой проект.
  • Инженерная культура. Навык формулировать наблюдения точно, воспроизводимо, без эмоций.

Зона ответственности стажёра (инженерная)

Что Где
Регистрация багов vault/bugs/ (write)
Обратная связь (предложения, наблюдения) vault/feedback/ (write)
Еженедельные метрики-агрегаты vault/reports/ (write)
Тестирование боевого стенда Стенд + Swagger

Что НЕ в зоне стажёра

  • Приоритизация багов — за PM.
  • Аппрув PR в wiki — за PM.
  • Классификация «баг vs недоработка» в спорных случаях — за PM. Стажёр делает первичную классификацию, финальное решение — за PM.
  • Продуктовые решения по QA — за PM.

Форма баг-репорта

Каждый баг — отдельная заметка в vault/bugs/. Обязательные поля:

---
title: "Краткое описание проблемы"
type: bug
status: open
severity: <critical|high|medium|low>
context: <ui|api|data|docs|other>
reported_by: Булат
reported_at: 2026-08-11
---

Тело заметки:

# <Краткое описание>

## Шаги воспроизведения

1. Зайти на ...
2. Нажать ...
3. Ввести ...

## Ожидаемое поведение

<Что должно было произойти>

## Фактическое поведение

<Что произошло на самом деле>

## Окружение

- Стенд: staging
- Браузер: <Chrome 120 / Firefox 115 / ...>
- Учетка: <какая роль>

## Вложения

<Скриншоты, ссылки на Swagger-запросы, JSON-ответы>

Классификация по severity

Severity Критерий Пример
critical Блокирует ключевую функциональность, нет обхода Не сохраняется образец, данные теряются
high Серьёзная проблема, но есть обход или проблема не блокирует Не работает фильтр, но поиск через API жив
medium Заметная проблема, не блокирует работу Некорректное форматирование даты в отчёте
low Косметика, мелкие UX-проблемы Опечатка в подписи кнопки

Если есть сомнения между двумя уровнями — стажёр ставит более высокий и отмечает в комментарии «уточнить severity». Финальное решение — за PM.

Классификация по context

Context Что значит
ui Проблема в интерфейсе (Blazor-страницы, компоненты)
api Проблема в REST/OData-эндпоинтах (проверяется через Swagger)
data Проблема с данными (некорректные значения, потери, расхождения)
docs Ошибка в документации или несоответствие доки и продукта
other Не попадает в категории выше

Еженедельные метрики

Раз в неделю стажёр собирает в vault/reports/ агрегаты по своим баг-репортам. Форма — отдельная заметка:

---
title: "QA-отчёт за неделю 2026-W32"
type: qa-report
report_period: 2026-W32   # год и номер недели ISO
reported_by: Булат
---

Тело:

# QA-отчёт за неделю 2026-W32

## Сводка

- Заведено багов: N
- Из них по severity: critical — N, high — N, medium — N, low — N
- Из них по context: ui — N, api — N, data — N, docs — N, other — N
- Закрыто (подтверждено командой): N

## Ключевые наблюдения

- <Тенденция или повторяющаяся проблема>

## Обратная связь

- <Что показалось непонятным в продукте>
- <Где документация расходится с реальностью>

Цель отчёта — не только цифры, но и наблюдения. Тренды важнее единичных багов: если пять багов в одной области — это сигнал.

Как тестировать без доступа к коду

У стажёра нет доступа к исходникам, но есть:

  • Стенд продукта — рабочее приложение. Тестировать как обычный пользователь.
  • Swagger/OpenAPI — все эндпоинты API видны. Можно дёргать напрямую и смотреть ответы.
  • Примеры JSON-ответов — эталонные структуры данных. Помогают понять, как данные устроены.

Стратегия тестирования:

  1. Читать docs/ в wiki — понимать, как функциональность должна работать.
  2. Пользоваться стендом как пользователь — проверять сценарии из документации.
  3. Сверять UI и API — то, что показывает UI, должно сходиться с тем, что возвращает API.
  4. Проверять граничные случаи — пустые значения, нули, очень большие числа, спецсимволы.
  5. Фиксировать наблюдения — даже если не уверен, что это баг. Лучше зафиксировать и уточнить у PM, чем пропустить.

Темп

Реалистичный темп при 10–15 ч/нед, с учётом параллельного учебного трека:

  • Первый месяц: знакомство с продуктом. 1–3 бага в неделю, любой severity.
  • Месяцы 2–3: стабильный поток. 3–5 багов в неделю, постепенный переход к более осмысленным находкам (high/medium).
  • Месяцы 4–6: качество важнее количества. Меньше багов, но с лучшей классификацией и анализом.

Темп не самоцель. Один хорошо оформленный баг с воспроизведением ценнее пяти «у меня тут не работает». На гейте оценивается качество репортов и глубина погружения в продукт, а не количество.

Связь с учебным треком

Тестирование боевого продукта помогает в проекте защиты:

  • Стажёр видит, как выглядит реальный ParameterValue, и точнее строит свой домен.
  • Swagger-ответы дают готовые образцы JSON для тестирования парсера на M1.
  • Понимание UX помогает в M4 строить осмысленный Blazor UI, а не абстрактный.

Обратная связь тоже работает: столкнувшись с null-handling в коде парсера (M1), стажёр точнее замечает проблемы с null в баг-репортах.

Дальше