Итоговый проект: защищаем тестовую модель

Ваш результат — проверяемый пакет

Представьте, что вы передаёте задачу другому QA за день до проверки релиза. Ему нужны не все ваши сообщения ассистенту, а версия правил, конкретные данные, порядок действий и основания ожиданий. Итоговый проект объединяет предыдущие уроки: разбор требований, классы и границы, таблицу решений, последовательности состояний и ревью покрытия. Пакет должен позволять начать работу без догадок.

Используйте учебную версию OD-1. Не заменяйте её реальными клиентскими задачами и не меняйте правила ради удобного результата. Укажите, что OrbitDesk и акторы синтетические. Если вы предлагаете улучшение продукта, вынесите его в вопросы к следующей версии спецификации. Отдельно обозначьте ограничения текущей проверки: например, сетевую неопределённость мы не моделировали.

Что положить в пакет

1. scope.md: границы анализа, версия OD-1, акторы и открытые вопросы.
2. conditions.csv: условия, правило, техника, ID проверки и приоритет с объяснением.
3. cases.md: шаги, данные, ожидаемый код и изменение либо отсутствие изменения.
4. fixtures.md: генераторы строк и их проверенные длины в кодовых точках.
5. review.md: исходный ошибочный ответ ИИ, ваши исправления и причины.
6. report.md: что спроектировано, что действительно выполнено и какое доказательство есть.

Как построить работу

Сначала самостоятельно выделите риски и шесть главных условий. Только затем сравните с предложениями ассистента или с готовым ошибочным ответом из задания. Такой порядок уменьшает привязку к первой красивой таблице. Помощник может расширить список, но каждое добавление должно пройти ваш фильтр: есть ли правило, выполнимы ли данные, отличается ли проверка от уже выбранной?

Затем подготовьте конкретный набор: title 0/1/2/79/80/81; description 0/1999/2000/2001; пробелы; Unicode; акторы автор-user, автор-editor, editor-неавтор и user-неавтор. Разведите причины отказов и выделите несколько сочетаний для приоритета R7. Не требуется механически получать произведение всех параметров: выбор нужно обосновать относительно рисков, а не скрывать за словом «всё».

Защитите один сквозной сценарий

В вашем пакете должна быть последовательность от создания draft до чтения published другим участником и повторной публикации. Для каждого шага укажите, кто действует и в каком состоянии объект. После 403/422/409 проверьте отсутствие изменения. После 200 проверьте опубликованный статус и неизменного автора. Одна только запись «ожидается успех» не проходит рубрику.

Если вы выполняете сценарии на собственной реализации OrbitDesk, запишите адрес согласованного стенда, версию сборки, время и наблюдение. Не называйте учебный контракт API уже работающим сервисом QA Orbit. Курс предоставляет спецификацию и фикстуры, а не удалённый endpoint. Без реализации можно выполнить статическое ревью, пересчёт строк и проверку модели; динамические сценарии честно остаются Not run.

Проверка качества перед сдачей

Возьмите случайный кейс и попробуйте выполнить его только по записанному тексту. Если приходится спрашивать, какой пользователь имеется в виду или откуда взят ожидаемый код, дополните артефакт. Проверьте, что ссылки на правила не устарели и что одна строка не одновременно Passed и Not run. Сравните матрицу с шестью различимыми исходами R7 и с выбранными границами.

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