В TMS лежит детальный ручной тест-кейс: осмысленный сценарий, теги, ссылки на задачу и четкий ожидаемый результат. Автоматизатор берет этот кейс, создает скелет автотеста и приступает к реализации.
Как правило, это происходит незаметно: ручной шаг могут удалить, объединить с другим или вынести в setup. Так он перестает быть явной проверкой бизнес-логики и превращается в «техническую подготовку», что размывает смысл такого теста. Иногда ручной шаг превращается в технический helper-метод. В итоге тест в отчёте успешен, хотя фактически бизнес-требование остаётся непроверенным.
Например, шаг «убедиться, что форма выглядит корректно» сложно перевести в код без уточнения критериев, а «подготовку пользователя» проще вынести в фикстуру.
Ручной шаг ≠ строка кода.
В ТестОпс реализована функция генерации кода, которая позволяет быстро создать шаблон автотеста на основе существующего тест-кейса и его атрибутов. Чтобы эта генерация не приводила к «пустым» зелёным тестам, ручной тест-кейс должен стать не просто инструкцией, а контрактом проверки. Он задаёт рамки: что проверяем, при каких условиях и какой результат считаем успешным.
В ТестОпс ручной кейс становится эталоном, каноническим описанием бизнес-задачи. Однако генерация не исправляет ошибки в самом сценарии: если он двусмыслен или устарел, эти проблемы неизбежно перекочуют в код.
Автоматизируемый шаг = управляемое действие и проверяемый результат. Если действие детерминировано, входные данные известны, а результат считывается через технический сигнал, шаг переносится в код почти напрямую.
Условия просты: состояние системы подготавливаемо, а механизм выполнения стабилен. Главное — чтобы в тесте был заложен объективный критерий успеха. Он должен быть оформлен как assertion (проверка состояния UI, API, БД или файла) и не зависеть от субъективного восприятия специалиста-тестировщика.
public void shouldSaveEmail() {
fillEmail()
save()
assertSuccessMessage()
assertProfileUpdated()
}Многие ручные шаги при автоматизации не исчезают, а меняют место. Они уходят из тела теста в фикстуры, helper-методы, фабрики данных или API-подготовку.
Принцип один: техническая подготовка не должна маскироваться под бизнес-проверку. Если шаг создаёт условия, а не проверяет поведение — выносите его из основного сценария.
Примеры таких методов: loginAs(role), createDraftOrder(), openUserProfile(userId) или submitFormWithValidData(). Так можно сохранить читаемость тестового сценария, избавляя его от списка технических кликов.
Пирамида тестирования приписывает хрупкость UI-тестам из-за зависимости от интерфейса. В подходе manual-first хрупкость иная — она в семантическом разрыве между описанием и кодом. Когда ручной кейс опирается на субъективные термины, автотест становится либо «пустым», либо имитацией проверки.
Ручной кейс оптимизирован под человека: длинные сценарии, переключение между экранами, ручной прогресс. Автотест — под машину: регулярность, точность сигнала и быстрая диагностика. Одна задача — разные режимы работы.
Форма автотеста часто отличается от ручного кейса. Чтобы приемка не стала субъективной, она должна базироваться на проверяемом контракте.
Рынок QA переходит от модели «делаем как получается» к управляемой функции. Ценность автоматизации теперь определяется не количеством тестов, а прозрачностью и устойчивостью контура качества. Инструменты должны стать инфраструктурой, связывающей требования, тесты и результаты в единую систему.