Linear помогает продуктовой и инженерной команде быстро вести рабочие задачи, обсуждать изменения и планировать итерации. Для QA эта скорость полезна, если дефекты сохраняют достаточный контекст: условие, влияние, ожидаемое поведение и доказательство исправления. Лёгкая карточка не должна превращаться в одно предложение «сломалась оплата». Хороший процесс в Linear оставляет детали там, где они нужны исполнителю, и делает состояние работы видимым без постоянных устных уточнений.
Issue, team, project и cycle
Issue — основная рабочая задача: дефект, улучшение или часть реализации. Team владеет процессом, статусами и задачами. Project объединяет связанные работы ради определённого результата, а cycle задаёт временную итерацию команды. Cycle не равен версии релиза: задачи из одной итерации могут поставляться отдельно, а большой выпуск охватывать несколько cycles. Для QA важно согласовать, где хранится целевая поставка и как найти именно ту сборку, которую предстоит проверять.
Статусы и метки как договорённость
Workflow определяется на уровне команды и может отличаться у соседних teams. Для очереди проверки можно договориться о статусе Ready for QA и понятном критерии выхода, но это пример настройки, а не обязательный стандарт Linear. Метки помогают обозначить bug, область продукта или тяжесть. Priority отражает порядок работы; severity при необходимости фиксируют отдельным соглашением. Не создавай десятки почти одинаковых меток, если потом никто не может построить устойчивую выборку критических дефектов.
Triage — входящая очередь, а не обещание исправления
Triage позволяет рассмотреть входящую проблему, уточнить данные, найти дубль и решить, принимать ли её в работу. Наличие задачи в этой очереди не означает назначения в текущий cycle. Важная особенность: triage-задачи по умолчанию исключаются из обычных представлений, пока их явно не включили соответствующим фильтром. Поэтому перед релизом проверь входящую очередь отдельно. Нулевая выдача Active issues не доказывает, что свежих критичных сообщений от поддержки нет.
Как писать дефект без лишнего объёма
Название показывает условие и эффект: «После смены тарифа счёт содержит старую цену». В описании нужны сборка, роль, данные, шаги, ожидаемое и фактическое значение. Укажи влияние и источник ожидания. Вложение должно подтверждать утверждение, а не заменять его. Для большого исследования оставь краткий вывод и ссылку на подробную диагностику, доступную исполнителю. Это сохраняет удобство Linear и одновременно позволяет воспроизвести проблему человеку, который не участвовал в разговоре.
Практика: изменение тарифа
Команда меняет биллинг. По требованиям новый тариф применяется к следующему расчётному периоду, а текущий оплаченный период не пересчитывается. В тестовом аккаунте есть действующая подписка и управляемые даты; реальные списания отключены. QA обнаружил, что предварительный счёт показывает старую цену для следующего периода. Чтобы дефект был полезен, нужно отделить неправильный расчёт от просто устаревшего текста интерфейса.
- 1.Найди похожие issues по тарифу, счёту и изменению периода. Проверь, совпадают ли исходное состояние подписки и источник неверной суммы.
- 2.Создай issue в ответственной team с тестовым тарифом, датами и ожидаемой ценой. Приложи безопасный ответ расчёта и отображаемое значение.
- 3.На triage согласуй влияние, владельца и приоритет. Свяжи проблему с проектом биллинга и зависимым изменением, если такая зависимость подтверждена.
- 4.После принятия в работу проверь, что задача попала в нужный план. Выбранный cycle отражает время работы, а сведения о поставке сохраняются отдельно по правилам команды.
- 5.Когда исправление доступно, повтори расчёт следующего периода и проверку текущего. Ожидаются новая цена только там, где она предусмотрена требованиями, и отсутствие реального списания.
- 6.Запиши сборку и результат retest, затем выполни согласованный переход. Завершённая разработка и подтверждённое поведение должны различаться в истории задачи.
Представления для QA
Создай понятные фильтры по team, статусу проверки, метке bug и нужному project. Отдельный срез полезен для блокирующих проблем и задач без владельца. Сначала проверь выборку на нескольких известных issues: дефект из triage, готовое исправление и завершённая задача должны отображаться по ожидаемым правилам. Linear использует собственные фильтры и views; вставлять JQL из Jira бессмысленно. Сохрани описание назначения представления, чтобы коллеги понимали, какой вопрос оно отвечает и что исключает.
Передача между командами
Если проблема оказалась в другом сервисе, перенос issue меняет контекст. По документации Linear при смене team может измениться идентификатор, статус отображается в workflow получателя, а некоторые свойства могут быть очищены или сопоставлены иначе. Поэтому после переноса проверь владельца, project, cycle, метки и фактическую очередь. Простая передача ссылки не гарантирует, что новая команда заметила задачу или согласилась с приоритетом. Оставь короткое техническое объяснение причины передачи.
Связи и автоматизация разработки
Отмечай реальные отношения blocks, blocked by, related и duplicate, чтобы виден был порядок работ. Интеграция с кодом может менять статусы после событий pull request, но merge не доказывает доступность исправления на тестовом стенде. Проверь настройки автоматизации и договорись, какое событие означает готовность к retest. Если pipeline обновляет задачу автоматически, комментарий о сборке должен позволять QA найти конкретный артефакт, а не гадать по последней ветке репозитория.
Границы тестовой документации
Issue хранит работу и обсуждение, но сам по себе не заменяет репозиторий повторяемых тест-кейсов с историей выполнений. Для маленького изменения достаточно ясных критериев приёмки и результата проверки; для большой регрессии нужна отдельная структура, связанная с проектом и сборкой. Не превращай каждый кейс в вечную issue только ради количества. Разделяй согласованное покрытие, фактический прогон и дефект, который возник в одном из запусков, чтобы отчёт не смешивал разные сущности.
Типичные ошибки и практический вывод
Частые ошибки — считать cycle релизом, игнорировать triage, закрывать дефект при merge и переносить issue между teams без проверки свойств. Другая крайность — компенсировать лёгкость интерфейса огромным шаблоном для любого косметического замечания. Хорошая работа QA в Linear сохраняет точность там, где она влияет на воспроизведение и решение. Результат — быстрая, понятная очередь и проверенные исправления с достаточной историей для следующего участника.