# Основы QA — рабочая тетрадь

Редакция QA Orbit · версия 2026-10-28.1

QA-CORE-1 — независимый учебный контракт, не спецификация настоящего портала и не OD-1 из курсов ИИ.
Q1. Создание задачи: title — строка длиной 1–80 кодовых точек Unicode включительно; исходное значение сохраняется без trim. description — строка длиной 0–500 кодовых точек Unicode; пустая допустима. null и числа в этих полях недопустимы.
Q2. priority: low | normal | high. Если поле отсутствует, сохраняется normal. Пустая строка и null недопустимы.
Q3. Создание доступно вошедшему участнику команды. Автор берётся из сессии, начальное состояние draft.
Q4. Черновик читает только автор. Опубликованную задачу читают все вошедшие участники той же команды. Другой команде задача недоступна.
Q5. Публикация: draft → published. Выполнить её может автор или editor той же команды, если title.trim() не пуст. Это отдельное право: editor не получает права читать чужой draft.
Q6. Повторная публикация published отклоняется. Отмена публикации и удаление не входят в эту версию.
Q7. Отказ не изменяет задачу и не создаёт новую. Успешная публикация меняет только state исходной задачи. Текст заголовка сохраняется точно.
Q8. В интерфейсе успешное создание показывает ID и состояние draft; успешная публикация — тот же ID и published; отказ показывает причину. Конкретные формулировки сообщений не заданы.
Акторы: Анна u-a user и Борис u-b user из команды north; Вера u-v editor из north; Олег u-o editor из south. Все данные синтетические.

## Качество, требования и приоритет проверки

В команду пришла версия, меняющая видимость задач и форму priority. До исполнения нужно сделать тест-анализ.

### Входные данные

QA-CORE-1 — независимый учебный контракт, не спецификация настоящего портала и не OD-1 из курсов ИИ.
Q1. Создание задачи: title — строка длиной 1–80 кодовых точек Unicode включительно; исходное значение сохраняется без trim. description — строка длиной 0–500 кодовых точек Unicode; пустая допустима. null и числа в этих полях недопустимы.
Q2. priority: low | normal | high. Если поле отсутствует, сохраняется normal. Пустая строка и null недопустимы.
Q3. Создание доступно вошедшему участнику команды. Автор берётся из сессии, начальное состояние draft.
Q4. Черновик читает только автор. Опубликованную задачу читают все вошедшие участники той же команды. Другой команде задача недоступна.
Q5. Публикация: draft → published. Выполнить её может автор или editor той же команды, если title.trim() не пуст. Это отдельное право: editor не получает права читать чужой draft.
Q6. Повторная публикация published отклоняется. Отмена публикации и удаление не входят в эту версию.
Q7. Отказ не изменяет задачу и не создаёт новую. Успешная публикация меняет только state исходной задачи. Текст заголовка сохраняется точно.
Q8. В интерфейсе успешное создание показывает ID и состояние draft; успешная публикация — тот же ID и published; отказ показывает причину. Конкретные формулировки сообщений не заданы.
Акторы: Анна u-a user и Борис u-b user из команды north; Вера u-v editor из north; Олег u-o editor из south. Все данные синтетические.

Заметка менеджера: «Всё должно работать быстро и удобно». Изменения релиза: новый фильтр команды; новое поле priority. Доступно 40 минут проверки. Учебное наблюдение O1: Борис открыл draft Анны и увидел title.

### Задание

1. Выделите три проверяемых правила и два вопроса к отсутствующим требованиям.
2. Предложите пять проверок с приоритетом и обоснованием риска.
3. Для O1 запишите ожидаемое и фактическое, не выдумывая причину в коде.
4. Обозначьте статус работы и что ещё нельзя утверждать.

### Самопроверка

- Каждое ожидание ссылается на Q-правило.
- Приоритет связан с изменением и возможным ущербом.
- O1 отделено от собственного исполнения.
- Не задан вымышленный SLA или точная причина дефекта.

### Разбор после самостоятельной попытки

Первые проверки: (1) Борис не читает draft Анны — Q4, высокий риск раскрытия; (2) Олег не читает published команды north — Q4, высокая изоляция команд; (3) Анна видит собственный draft — Q4, базовая доступность; (4) отсутствие priority даёт normal — Q2, совместимость старого клиента; (5) priority="urgent" отклоняется без создания — Q2/Q7. Вопросы: какие измеримые условия быстродействия согласованы; какие браузеры/условия доступности входят в выпуск. O1: ожидается отказ в выдаче содержимого по Q4, в предоставленном наблюдении title выдан; это противоречие, причина пока неизвестна. Статус: тест-анализ выполнен, динамические проверки нами не запускались; качество всей сборки не установлено.

Типичные ошибки:

- Считать слово «быстро» готовым порогом.
- Перепутать серьёзность риска с порядком исправления без обсуждения контекста.
- Назвать учебную трассу собственным выполненным тестом.

## Классы эквивалентности и границы

Нужно покрыть данные формы отдельно от правил публикации.

### Входные данные

QA-CORE-1 — независимый учебный контракт, не спецификация настоящего портала и не OD-1 из курсов ИИ.
Q1. Создание задачи: title — строка длиной 1–80 кодовых точек Unicode включительно; исходное значение сохраняется без trim. description — строка длиной 0–500 кодовых точек Unicode; пустая допустима. null и числа в этих полях недопустимы.
Q2. priority: low | normal | high. Если поле отсутствует, сохраняется normal. Пустая строка и null недопустимы.
Q3. Создание доступно вошедшему участнику команды. Автор берётся из сессии, начальное состояние draft.
Q4. Черновик читает только автор. Опубликованную задачу читают все вошедшие участники той же команды. Другой команде задача недоступна.
Q5. Публикация: draft → published. Выполнить её может автор или editor той же команды, если title.trim() не пуст. Это отдельное право: editor не получает права читать чужой draft.
Q6. Повторная публикация published отклоняется. Отмена публикации и удаление не входят в эту версию.
Q7. Отказ не изменяет задачу и не создаёт новую. Успешная публикация меняет только state исходной задачи. Текст заголовка сохраняется точно.
Q8. В интерфейсе успешное создание показывает ID и состояние draft; успешная публикация — тот же ID и published; отказ показывает причину. Конкретные формулировки сообщений не заданы.
Акторы: Анна u-a user и Борис u-b user из команды north; Вера u-v editor из north; Олег u-o editor из south. Все данные синтетические.

Базовый вход B: {title:"План", description:"", priority:"normal"}, вошла Анна. Каждая проверка начинается с чистого набора задач. Под «А×N» понимается N повторений кириллической А.

### Задание

1. Составьте шесть проверок длины title трёхточечным способом.
2. Добавьте три проверки типов и три проверки priority, не совмещая независимые нарушения.
3. Укажите условия успешного создания и проверку отсутствия записи при отказе.
4. Отдельно объясните разницу создания и публикации title="   ".

### Самопроверка

- Есть длины 0,1,2,79,80,81 с корректными ожиданиями.
- Типы не смешаны с диапазоном строковых длин.
- Отсутствие priority ожидает default normal.
- Каждый отказ проверяет отсутствие созданной задачи.

### Разбор после самостоятельной попытки

Title: "" → отказ; А×1, А×2, А×79, А×80 → новый ID, draft, точный title; А×81 → отказ. Три типа: null → отказ; 42 → отказ; отсутствующий title → отказ. Priority при валидном B: high → сохранён high; поле отсутствует → сохранён normal; urgent → отказ. Это 12 примеров, но не полная модель всех данных: например, description и другие разрешённые priority ещё требуют покрытия. При каждом отказе число и содержимое задач не меняются. title="   " имеет длину 3, поэтому создание проходит Q1; его публикация отклоняется Q5 без изменения title/state. Статус этого задания — спроектировано; самостоятельного запуска нет.

Типичные ошибки:

- Считать JS length длиной в кодовых точках для любых строк.
- Пропустить 80 как последнее допустимое значение.
- Ожидать отказ создания пробельного title, перенеся правило публикации.

## Таблицы решений и переходы состояний

Коллега предлагает одну проверку «editor видит и публикует любой черновик». Разберите её на независимые правила.

### Входные данные

QA-CORE-1 — независимый учебный контракт, не спецификация настоящего портала и не OD-1 из курсов ИИ.
Q1. Создание задачи: title — строка длиной 1–80 кодовых точек Unicode включительно; исходное значение сохраняется без trim. description — строка длиной 0–500 кодовых точек Unicode; пустая допустима. null и числа в этих полях недопустимы.
Q2. priority: low | normal | high. Если поле отсутствует, сохраняется normal. Пустая строка и null недопустимы.
Q3. Создание доступно вошедшему участнику команды. Автор берётся из сессии, начальное состояние draft.
Q4. Черновик читает только автор. Опубликованную задачу читают все вошедшие участники той же команды. Другой команде задача недоступна.
Q5. Публикация: draft → published. Выполнить её может автор или editor той же команды, если title.trim() не пуст. Это отдельное право: editor не получает права читать чужой draft.
Q6. Повторная публикация published отклоняется. Отмена публикации и удаление не входят в эту версию.
Q7. Отказ не изменяет задачу и не создаёт новую. Успешная публикация меняет только state исходной задачи. Текст заголовка сохраняется точно.
Q8. В интерфейсе успешное создание показывает ID и состояние draft; успешная публикация — тот же ID и published; отказ показывает причину. Конкретные формулировки сообщений не заданы.
Акторы: Анна u-a user и Борис u-b user из команды north; Вера u-v editor из north; Олег u-o editor из south. Все данные синтетические.

Исходные объекты north: q1 author=u-a, title="План", state=draft; q2 author=u-a, title="   ", state=draft; q3 author=u-a, title="Релиз", state=published. Каждый сценарий берёт свежую копию этих данных. Олег состоит только в south.

### Задание

1. Постройте по три проверки чтения и публикации с разными акторами.
2. Запишите последовательность Анна публикует q1, затем повторяет команду.
3. Объясните, какие права Веры различаются и почему.
4. Укажите, чем подтвердить отсутствие лишней копии после успеха.

### Самопроверка

- Чтение чужого draft editor ожидает отказ.
- Публикация чужого draft editor с непустым title допускается.
- Повторная команда сохраняет published и исходный ID.
- Обоснование относится к Q4–Q7 и не выдаёт предположение за запуск.

### Разбор после самостоятельной попытки

Чтение: Анна/q1 → разрешено; Вера/q1 → отказ; Борис/q3 → разрешено. Публикация на независимых снимках: Вера/q1 → published (Q5); Борис/q1 → отказ (нет авторства/editor); Анна/q2 → отказ (trim пуст). Отдельно Олег/q1 → отказ принадлежности другой команде. Последовательность: Анна/q1/draft → успех, q1/published; повтор → отказ, q1/published. ID q1 и точный title="План" сохраняются. Для Q7 сравнивается контролируемый список ID/число задач до и после: после публикации не должно быть нового ID. Матрица покрывает выбранные правила и переходы, но не все роли/данные продукта. Статус: разработаны сценарии, выполнение не проводилось.

Типичные ошибки:

- Считать editor универсальным разрешением на чтение.
- Проверять повторную публикацию на новом draft.
- Заявить отсутствие копии после единственного GET прежнего ID.

## Исследовательская сессия и полезный баг-репорт

Вы получили запись исследовательской сессии, но не имеете запускаемой сборки. Нужен репорт, который не скрывает этот факт.

### Входные данные

QA-CORE-1 — независимый учебный контракт, не спецификация настоящего портала и не OD-1 из курсов ИИ.
Q1. Создание задачи: title — строка длиной 1–80 кодовых точек Unicode включительно; исходное значение сохраняется без trim. description — строка длиной 0–500 кодовых точек Unicode; пустая допустима. null и числа в этих полях недопустимы.
Q2. priority: low | normal | high. Если поле отсутствует, сохраняется normal. Пустая строка и null недопустимы.
Q3. Создание доступно вошедшему участнику команды. Автор берётся из сессии, начальное состояние draft.
Q4. Черновик читает только автор. Опубликованную задачу читают все вошедшие участники той же команды. Другой команде задача недоступна.
Q5. Публикация: draft → published. Выполнить её может автор или editor той же команды, если title.trim() не пуст. Это отдельное право: editor не получает права читать чужой draft.
Q6. Повторная публикация published отклоняется. Отмена публикации и удаление не входят в эту версию.
Q7. Отказ не изменяет задачу и не создаёт новую. Успешная публикация меняет только state исходной задачи. Текст заголовка сохраняется точно.
Q8. В интерфейсе успешное создание показывает ID и состояние draft; успешная публикация — тот же ID и published; отказ показывает причину. Конкретные формулировки сообщений не заданы.
Акторы: Анна u-a user и Борис u-b user из команды north; Вера u-v editor из north; Олег u-o editor из south. Все данные синтетические.

Учебный журнал U1: сборка учебная 0.9.7, браузер Chromium, ОС не записана, вошла Анна. title=А×80 создаётся; title=😀×80 дважды получает «Слишком длинный заголовок», записи не появляются. Прочие поля description="", priority=normal. Чистый снимок перед каждой попыткой. Самостоятельного доступа к этой сборке нет.

### Задание

1. Напишите баг-репорт с воспроизводимыми входами и ссылкой на Q1.
2. Отделите сведения журнала, неизвестное окружение и гипотезу причины.
3. Предложите три шага для минимизации и три проверки после исправления.
4. Объясните влияние и предложенный приоритет с оговоркой политики команды.

### Самопроверка

- 80 эмодзи трактуются как 80 кодовых точек выбранного символа.
- Ожидаемое содержит создание draft с точным title.
- ОС и собственное воспроизведение не выдуманы.
- Гипотеза UTF-16 помечена предположением.

### Разбор после самостоятельной попытки

Заголовок: «Создание отклоняет допустимый title из 80 эмодзи (QA-CORE-1 Q1)». Сведения: анализ учебного U1 для 0.9.7/Chromium, ОС неизвестна; самостоятельно не запускалось. Шаги: войти Анной; на чистом снимке задать 😀×80, description="", priority=normal; создать. Ожидание: новый ID, draft, исходный title из 80 кодовых точек. Факт по U1: отказ «Слишком длинный заголовок», записи нет, повторяется 2/2. Сравнение: А×80 сохраняется. Влияние: допустимые заголовки части пользователей блокируются; proposed medium, порядок исправления обсуждается с командой. Гипотеза: используются кодовые единицы UTF-16 вместо кодовых точек, не подтверждена. Уточнить ОС, версию браузера, значение входа и независимый запуск. План минимизации (ещё не исполнен): 1) убрать все необязательные поля и оставить один повторяемый символ вместо произвольного текста; 2) сравнить 79/80/81 повторов при фиксированных остальных данных, сохраняя исходный сбой; 3) сравнить А×80 и 😀×80 на чистых снимках, чтобы изолировать различие символов. Ретест на новой сборке: исходные 😀×80; регресс А×79/80/81 и точное сохранение пробельного title. Необязательный ориентир для отдельного запуска HTML-модели: на 0.9.7 А×80 проходит, 😀×80 отклоняется; на 0.9.8 и 0.9.9 оба проходят. Борис читает q1 на 0.9.7 и 0.9.8 — это намеренное нарушение Q4; на 0.9.9 получает отказ. Олег не читает q3 ни на одной сборке. Собственные факты запуска относятся к этой модели и не приписываются выданному журналу U1.

Типичные ошибки:

- Написать «воспроизводится у меня», имея только журнал.
- Указать точную версию ОС из предположения.
- Назвать причину в коде установленной по одному симптому.

## Регресс, статусы и решение о выпуске

Нужно дать короткую рекомендацию по готовности, не скрывая непроверенные области.

### Входные данные

QA-CORE-1 — независимый учебный контракт, не спецификация настоящего портала и не OD-1 из курсов ИИ.
Q1. Создание задачи: title — строка длиной 1–80 кодовых точек Unicode включительно; исходное значение сохраняется без trim. description — строка длиной 0–500 кодовых точек Unicode; пустая допустима. null и числа в этих полях недопустимы.
Q2. priority: low | normal | high. Если поле отсутствует, сохраняется normal. Пустая строка и null недопустимы.
Q3. Создание доступно вошедшему участнику команды. Автор берётся из сессии, начальное состояние draft.
Q4. Черновик читает только автор. Опубликованную задачу читают все вошедшие участники той же команды. Другой команде задача недоступна.
Q5. Публикация: draft → published. Выполнить её может автор или editor той же команды, если title.trim() не пуст. Это отдельное право: editor не получает права читать чужой draft.
Q6. Повторная публикация published отклоняется. Отмена публикации и удаление не входят в эту версию.
Q7. Отказ не изменяет задачу и не создаёт новую. Успешная публикация меняет только state исходной задачи. Текст заголовка сохраняется точно.
Q8. В интерфейсе успешное создание показывает ID и состояние draft; успешная публикация — тот же ID и published; отказ показывает причину. Конкретные формулировки сообщений не заданы.
Акторы: Анна u-a user и Борис u-b user из команды north; Вера u-v editor из north; Олег u-o editor из south. Все данные синтетические.

Выданный учебный журнал R-12: 8 planned. T1 создание обычного draft — Passed; T2 А×80 — Passed; T3 А×81 отказ без записи — Passed; T4 😀×80 — Passed (ретест U1); T5 Борис читает draft Анны — Failed, title выдан; T6 изоляция south — Blocked, нет рабочего аккаунта; T7 повтор публикации — Not run; T8 отсутствие priority — Not run. Сборка 0.9.8, Chromium, одна конфигурация. Самостоятельный прогон не выполнялся.

### Задание

1. Сведите численные итоги без исключения Blocked/Not run из planned.
2. Выделите подтверждённое исправление и незакрытый дефект.
3. Напишите рекомендацию и план следующего часа.
4. Назовите пределы применимости результатов.

### Самопроверка

- Итог 4 Passed / 1 Failed / 1 Blocked / 2 Not run, всего 8.
- T4 отмечен как ретест по журналу, а T5 — незакрытый риск утечки.
- Blocked не засчитан успешным.
- Нет заявления о всех браузерах или принятии риска бизнесом.

### Разбор после самостоятельной попытки

По предоставленному R-12 на 0.9.8: planned 8, executed 5 (4 Passed, 1 Failed), Blocked 1, Not run 2. T4 подтверждает исправление U1 в условиях журнала. T5 нарушает Q4: чужой draft раскрывается, поэтому рекомендую не выпускать до исправления либо отдельного уполномоченного решения по этому риску. T6 оставляет изоляцию команд неизвестной, а не успешной. Следующие действия: передать точный T5 разработке; восстановить синтетический south-аккаунт; выполнить T6; после новой сборки ретест T5 и регресс видимости; затем T7/T8. Область ограничена одним браузером и указанными данными; быстродействие и другие конфигурации не проверены. Мы анализировали учебные записи, самостоятельного динамического прогона не проводили.

Типичные ошибки:

- Показать 4 из 5 и назвать это общим покрытием 80%.
- Перенести Passed с другой сборки без анализа применимости.
- Объявить Blocked проверенной функциональностью.

## Итоговый проект: пакет проверки релиза

Команда меняет видимость и Unicode-валидацию. Нужно передать пакет проверки коллеге и рекомендацию по выпуску.

### Входные данные

QA-CORE-1 — независимый учебный контракт, не спецификация настоящего портала и не OD-1 из курсов ИИ.
Q1. Создание задачи: title — строка длиной 1–80 кодовых точек Unicode включительно; исходное значение сохраняется без trim. description — строка длиной 0–500 кодовых точек Unicode; пустая допустима. null и числа в этих полях недопустимы.
Q2. priority: low | normal | high. Если поле отсутствует, сохраняется normal. Пустая строка и null недопустимы.
Q3. Создание доступно вошедшему участнику команды. Автор берётся из сессии, начальное состояние draft.
Q4. Черновик читает только автор. Опубликованную задачу читают все вошедшие участники той же команды. Другой команде задача недоступна.
Q5. Публикация: draft → published. Выполнить её может автор или editor той же команды, если title.trim() не пуст. Это отдельное право: editor не получает права читать чужой draft.
Q6. Повторная публикация published отклоняется. Отмена публикации и удаление не входят в эту версию.
Q7. Отказ не изменяет задачу и не создаёт новую. Успешная публикация меняет только state исходной задачи. Текст заголовка сохраняется точно.
Q8. В интерфейсе успешное создание показывает ID и состояние draft; успешная публикация — тот же ID и published; отказ показывает причину. Конкретные формулировки сообщений не заданы.
Акторы: Анна u-a user и Борис u-b user из команды north; Вера u-v editor из north; Олег u-o editor из south. Все данные синтетические.

U1 / 0.9.7: А×80 успешно, 😀×80 отказ (2/2), новая запись отсутствует. R-12 / 0.9.8: T1 обычный draft Passed; T2 А×80 Passed; T3 А×81 отказ без записи Passed; T4 😀×80 Passed; T5 Борис читает draft Анны Failed (title выдан); T6 south Blocked (нет аккаунта); T7 повтор публикации Not run; T8 default priority Not run. Все журналы синтетические. Время на следующий прогон — 60 минут. Собственного доступа к этой сборке нет.

### Задание

1. Составьте 12–16 различимых тестов: данные, роли, команды, состояния и отсутствие побочных эффектов.
2. Приложите шесть длин title и таблицу публикации с исходными состояниями.
3. Оформите дефект раскрытия draft по T5 и отделите неизвестные детали.
4. Дайте сводку R-12 и риск-ориентированный план следующего часа.
5. Проверьте прослеживаемость: Q-правило → тест → свидетельство/Not run → вывод.

### Самопроверка

- Все ожидания относятся к QA-CORE-1, неизвестные требования вынесены в вопросы.
- Есть разные роли/команды, отрицательные данные и запрещённый повторный переход.
- Точные входы, состояния и наблюдения позволяют передать тесты другому человеку.
- Журналы не выданы за собственное исполнение, числа 4/1/1/2 сходятся.
- Вывод учитывает нарушение Q4 и неизвестную изоляцию south.

### Разбор после самостоятельной попытки

Каркас сильного проекта: P01–P06 длины 0/1/2/79/80/81; P07 title=null; P08 отсутствие priority → normal; P09 urgent → отказ без записи; P10 Анна читает свой draft; P11 Борис читает draft Анны → отказ; P12 Олег читает published north → отказ; P13 Вера публикует чужой draft с title="План" → published без изменения ID/title; P14 Вера читает тот же draft на независимом снимке → отказ; P15 Анна публикует пробелы → отказ; P16 Анна публикует непустой draft и повторяет → второй отказ, published неизменён. Новые тесты Not run. Отдельно импортируется R-12: 8 planned, 4 Passed, 1 Failed, 1 Blocked, 2 Not run; U1 ретестируется T4 на 0.9.8. Дефект T5 указывает автора/читателя/состояние, Q4, выдачу title и неизвестные детали окружения. Рекомендация: не выпускать без решения по утечке; следующий час — исправление/ретест Q4, восстановление south, изоляция, повтор публикации и default. Вопросы: SLA, список конфигураций, процесс приёмки риска.

Типичные ошибки:

- Скопировать только названия тестов без конкретных данных.
- Записать новые спроектированные тесты Passed.
- Путать QA-CORE-1 с одноимёнными сущностями из курсов ИИ.

## Источники

Техники и термины: [официальный ISTQB CTFL 4.0.1](https://istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf). Задания, контракт и разборы оригинальные; аккредитация не заявляется.