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

Что именно делает QA

Качество относится к способности продукта удовлетворять нужды заинтересованных людей в конкретных условиях. Тестирование даёт сведения об этих условиях и рисках. Оно включает анализ документов до появления кода, проектирование примеров, выполнение проверок и объяснение результатов. Даже аккуратный набор успешных проверок не доказывает отсутствие всех дефектов: вы проверяете ограниченные данные, состояния и окружения.

Разделяйте ошибку человека, дефект артефакта и наблюдаемый сбой. Например, разработчик неверно прочитал «1–80 включительно», написал ограничение меньше 80, и форма отказала на 80 буквах. Мы видим сбой; точную причину в коде выясняют отдельно. Эта привычка помогает писать точные сообщения без необоснованных обвинений. Проверка проверяемого поведения полезнее предположения о чужой ошибке.

Проверяемое правило и открытый вопрос

Хорошее правило позволяет двум людям независимо получить одинаковое ожидание на одном входе. Фраза «задача быстро сохраняется» этого не обеспечивает: нет порога времени, условий нагрузки, начала и конца измерения. «После нажатия Сохранить пользователь видит ID созданной задачи» уже задаёт наблюдение, но ещё не определяет допустимую задержку. Запишите это ограничение вместо придуманного SLA.

В QA-CORE-1 длина title измеряется кодовыми точками Unicode, не байтами и не визуальными символами. Поэтому русская буква и латинская буква дают по единице; составной видимый символ может состоять из нескольких кодовых точек. Ссылка на Q1 полезна именно потому, что устраняет такую неоднозначность. Правило из другой версии учебного кейса сюда автоматически не переносится. Статический разбор требований уже может обнаружить отсутствие правила, даже если выполнить приложение нельзя.

Риск определяет порядок, но не заменяет покрытие

Оцените, что случится при дефекте и насколько правдоподобен такой дефект после изменения. Для учебного релиза изменён фильтр видимости: раскрытие чужого черновика имеет серьёзный ущерб и прямо связано с изменённым кодом. Проверка недопустимого priority тоже нужна, но её можно поставить после проверки изоляции. Цифровая шкала удобна для обсуждения, однако произведение двух субъективных баллов не превращается в точную вероятность.

У каждой первой проверки запишите риск, входное состояние, действие и наблюдаемый результат. «Проверить безопасность» слишком широко. «Борис открывает draft Анны; содержание не выдаётся; состояние задачи не меняется» — уже различимый сценарий по Q4 и Q7. Если интерфейс для чужого draft показывает нейтральную ошибку без названия, это не доказывает все серверные ограничения. Сохраняйте границу вывода и отдельно планируйте проверку других каналов доступа.

Отделите основания