QA The Other WayОбеспечение качества в эпоху тестов, написанных искусственным интеллектом. QA The Other Way.
Практическое QA

Мягкой проверке всё равно нужна жёсткая остановка.

Собирайте независимые ошибки, не позволяя нарушенному условию разрешить следующее действие.

5 мин. чтенияQA The Other Way
Авторская схема наблюдений и жёсткого барьера перед зависимым действием.
Авторская редакционная иллюстрация.
Иллюстративное видео к этой статье. английский экранный текст; выберите субтитры для этого языка.

Переведенное издание. Технические идентификаторы остаются в своей первоначальной форме.

Собирайте независимые ошибки, не позволяя нарушенному условию разрешить следующее действие.
Локальный пример раннера с вымышленными данными, не интерфейс клиента или поставщика.

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

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

Собирайте осмысленные наблюдения

Мягкие ошибки не прекращают исполнение, но делают тест неуспешным. Они работают с раннером Playwright, а не автоматически с другой библиотекой.

Следующее наблюдение должно сохранять смысл после предыдущей ошибки. Неверный заголовок не мешает независимой проверке статуса. Отсутствующая исходная запись иная: чтение её полей может породить бесполезные вторичные ошибки.

await expect.soft(page.getByRole('heading')).toHaveText('Review demo draft');
await expect.soft(page.getByRole('status')).toHaveText('Ready for review');
expect(test.info().errors).toHaveLength(0);
await page.getByRole('button', { name: 'Continue demo' }).click();

Нужны контролируемая страница и импортированные test и expect. Жёсткая проверка ошибок намеренна. После мягкой ошибки Continue не нажимается. Локальная кнопка не задаёт правило для настоящего согласования.

Поставьте барьер перед зависимой операцией

Остановитесь до действия, смысл которого зависит от проверенного состояния. В конце поздно: неправильная запись уже могла измениться. Выбирайте по зависимостям, а не ради длинного списка ошибок.

Ошибки доступны в test.info().errors. Не очищайте массив и не меняйте статус ради видимости успеха. Поздний скриншот не стирает неудачу.

Дополнительные чтения должны оставаться осмысленными и разрешёнными. Даже чтение может раскрыть приватные данные в трассировке. Используйте разрешённые тестовые записи и проверяйте файлы перед передачей.

Проверьте отрицательный случай

Локальный пример содержит два расхождения. Раннер сохраняет оба, затем барьер останавливает исполнение. Проверка после теста подтверждает неизменность кнопки. Намеренный неуспешный запуск остаётся неуспешным, не выдаётся за производственный успех.

Другой случай с верными данными проходит барьер и меняет локальный маркер. Это доказывает управление потоком, не защиту сервера и не свойство всех сгенерированных тестов.

Для критичного условия обычная жёсткая проверка может быть проще. Мягкость служит диагностике, не требует откладывать все ошибки. Используйте обе формы по смыслу.

Оставьте правило для ревью

Запишите независимые проверки, зависимое действие и место остановки. Так виден сценарий, который собирает ошибки, но всё равно действует дальше.

AnyTest описывает исследование приложений и сквозные тесты для проверки человеком. Спросите, сохраняется ли ошибка и защищены ли зависимые операции. Особая реализация мягких проверок AnyTest не заявляется. Диагностика не должна ослаблять границу.

Общие вопросы

Оставляет ли мягкая ошибка тест зелёным?

Нет. Выполнение продолжается, но тест отмечается как неуспешный.

Где должен стоять жёсткий барьер?

Перед зависимым действием, а не только в конце сценария.

Источники