Весь курс вы выполняли проверки вручную — по тест-кейсам (глава 6), исследовательски (глава 10), с помощью ИИ-ассистента как ускорителя черновика (глава 14). Но часть проверок в реальных командах выполняет не человек, а код: автоматизированные тесты. Пирамиду таких тестов вы уже видели мельком в главе 2.5 — сейчас, дойдя до конца курса, разберём её глубже: не практику написания кода (это отдельный продвинутый курс, требующий знания Python), а то, что вообще стоит автоматизировать, что почти никогда не стоит, и чем на практике занимается automation QA — специализация, отдельная от вашей.
Чему научишься за этот урок:
— уточнять уже знакомую по главе 2.5 пирамиду тестирования на примере API (главаи объяснять, почему нижние уровни автоматизируют охотнее верхних;
— применять понятие ROI (окупаемость) к решению, автоматизировать проверку или нет;
— называть, что почти никогда не стоит автоматизировать;
— отличать роль automation QA от своей роли manual QA.
Пирамида тестирования: что уже знаете и что уточним
Пирамиду тестирования вы уже видели в главе 2.5: баланс уровней автотестов, где в основании — unit-тесты (много, быстро, дёшево), а на вершине — e2e/UI-тесты (мало, медленно, дорого). Средний уровень там был назван «интеграционные» — сейчас, когда вы прошли главу 8 про API, можно уточнить: на практике интеграционный уровень чаще всего и есть тесты API и сервисов (запросы и ответы, глава — они не зависят от того, как выглядит интерфейс, поэтому стабильнее и дешевле в поддержке, чем UI-тесты, но дороже unit-тестов, которые пишут разработчики для отдельных функций кода напрямую. Общий принцип пирамиды остаётся тем же: чем выше уровень, тем меньше таких тестов должно быть — не потому что UI не важен, а потому что UI-тесты (глава 7: любое изменение вёрстки может их сломать, даже если сама функциональность работает правильно) дороже всего поддерживать.
/\
/UI\ <- меньше всего: медленно, дорого,
/------\ часто ломается от вёрстки (глава 7)
/ API / <- интеграционный уровень (глава 2.5) на
/--------\ практике = тесты API (глава 8)
/ UNIT \ <- больше всего: быстро, дёшево,
/--------------\ пишут разработчики
ROI: когда автоматизация вообще окупается
ROI (return on investment, окупаемость) — вопрос, окупятся ли время и деньги, потраченные на написание и поддержку автоматизированного теста, тем, сколько раз он реально прогонится. Написать и поддерживать автотест стоит дороже, чем один раз проверить вручную. Автоматизация окупается там, где проверку выполняют часто и повторяемо: вспомните регрессионное тестирование (глава 2.5) — один и тот же набор проверок гоняют перед каждым релизом, десятки раз за жизнь продукта. А вот проверка, которую нужно выполнить один раз (например, разовая миграция данных) или функциональность, интерфейс которой меняется каждую неделю на этапе активной разработки, — плохие кандидаты: автотест либо не успеет окупиться, либо придётся переписывать его быстрее, чем он принесёт пользу.
Что почти никогда не стоит автоматизировать
- Исследовательское тестирование (глава 10). Суть подхода — придумывать следующий шаг по результату предыдущего, реагируя на то, что реально видит человек. Автоматический скрипт выполняет заранее заданные шаги — он не умеет исследовать непредвиденное.
- Оценку юзабилити (глава 7.6). «Удобно ли это?» — вопрос о человеческом восприятии, а не о том, вернул ли сервер ожидаемый код ответа. Автотест может проверить, что кнопка кликабельна, но не может оценить, раздражает ли пользователя её расположение.
- Разовые или очень нестабильные проверки. Из-за ROI: если проверка выполняется один раз или интерфейс меняется быстрее, чем успевает окупиться поддержка теста, — автоматизация невыгодна экономически, даже если технически возможна.
Чем занимается automation QA
Automation QA — отдельная специализация, а не следующая ступень карьеры «после» manual QA автоматически. Automation QA пишет и поддерживает код автотестов (инструменты вроде Selenium или Playwright для UI, pytest для организации тестов, шаблон Page Object Model для структуры кода — вы не изучаете это в данном курсе, это отдельный продвинутый курс с зависимостью от Python), настраивает их запуск в рамках CI/CD и решает, на каком уровне пирамиды писать очередной тест. Но automation QA не отменяет manual QA: решение, ЧТО именно стоит автоматизировать, часто принимается вместе с ручным тестировщиком, который знает продукт и его риски (глава 13.3), а находить НОВЫЕ, ранее неизвестные баги в исследовательском режиме (глава 10) по-прежнему может только человек — автотест проверяет только то, что в него заранее заложили.
На собеседовании достаточно уверенно объяснить идею пирамиды, что такое ROI простыми словами и назвать, что не стоит автоматизировать (исследовательское тестирование, юзабилити). Писать код автотестов на этом курсе не учат — это честное ограничение, а не пробел, который нужно скрывать.
Итог:
— пирамида тестирования (уже известна из главы 2.5): unit-тесты (дёшево, много) → интеграционный уровень, на практике — тесты API (глава
— ROI решает, окупится ли автоматизация: подходит регрессионное тестирование (глава 2.5), не подходят разовые проверки и часто меняющийся интерфейс;
— почти никогда не автоматизируют исследовательское тестирование (глава 10) и оценку юзабилити (глава 7.6) — там нужно человеческое суждение;
— automation QA — отдельная специализация, которая пишет и поддерживает код тестов, но не заменяет manual QA в поиске новых багов.
Контрольный вопрос. Согласно пирамиде тестирования, каких автоматизированных тестов должно быть больше всего?
Подсказка: Вспомни, какой уровень пирамиды находится в основании — самом широком месте.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Почему UI-тесты находятся на вершине пирамиды, а не в основании?
Подсказка: Вспомни, что происходит с UI-тестом при любом изменении вёрстки (глава 7).
Онлайн-проверка ответа появится позже
Контрольный вопрос. Что означает ROI применительно к решению об автоматизации проверки?
Подсказка: Термин расшифровывается как «return on investment» — окупаемость вложений.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Почему оценку юзабилити (глава 7.6) почти никогда не автоматизируют?
Подсказка: Вспомни, чем вопрос «удобно ли это» отличается от вопроса «вернул ли сервер нужный код ответа».
Онлайн-проверка ответа появится позже
Контрольный вопрос. Какие проверки урок называет хорошими кандидатами на автоматизацию по критерию ROI (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Два варианта повторяются часто и стабильны — то, что урок называет хорошей окупаемостью. Два других — плохие кандидаты по причине, названной в уроке.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Как называется модель, которая делит автоматизированные тесты на уровни (unit, API, UI) и показывает, каких должно быть больше, а каких меньше? Ответь одним словом.
Подсказка: Название модели совпадает с геометрической фигурой, у которой широкое основание и узкая вершина.
Онлайн-проверка ответа появится позже
Задание. Тестировщик решает, автоматизировать ли проверку, которая гоняется перед каждым релизом на протяжении всей жизни продукта. Какой уровень пирамиды тестирования подойдёт лучше всего, если проверка обращается напрямую к запросам и ответам, минуя интерфейс? Ответь одним словом на английском.
Подсказка: Вспомни средний уровень пирамиды из урока — тот, что связан с главой 8.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Онлайн-проверка ответа появится позже
Задание. Команда хочет автоматизировать оценку того, насколько удобно пользователю проходить регистрацию — нравится ли ему порядок экранов. К какой из категорий «почти никогда не автоматизируют» из этого урока относится такая задача? Ответь одним словом.
Подсказка: Вспомни, к какой категории «почти никогда не автоматизируют» относится оценка удобства — как эта категория называется в уроке.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Онлайн-проверка ответа появится позже
Задание. Объясни в 2-3 предложениях, почему exploratory-тестирование (глава 10) почти никогда не автоматизируют, даже если технически написать скрипт, кликающий по случайным элементам страницы, возможно.
Подсказка: Вспомни определение исследовательского тестирования из главы 10 — чем оно принципиально отличается от выполнения заранее заданных шагов.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Задание. Команда обсуждает, какие из четырёх проверок автоматизировать в первую очередь при ограниченном бюджете: (1) регрессионный набор из 50 проверок API оплаты курса, гоняется перед каждым релизом уже год; (2) разовая сверка данных после миграции базы, которая больше не повторится; (3) юзабилити-оценка нового экрана оформления заказа; (4) проверка API каталога курсов (глава 8), стабильная уже полгода, тоже часть регресса. Распредели все четыре проверки по приоритету автоматизации (от «точно автоматизировать» до «не автоматизировать вовсе») и обоснуй порядок, опираясь на пирамиду и ROI из этого урока.
Подсказка: Для каждой из четырёх проверок отдельно ответь на два вопроса: как часто она повторяется (ROI) и требует ли она человеческого суждения (юзабилити vs API/регресс).
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Что дальше
Мы разобрали, как решить, что стоит автоматизировать, а что нет, и чем занимается automation QA — без единой строчки кода, это отдельная тема продвинутого курса. Это был обзорный мост между ручным тестированием и автоматизацией — дальше в курсе сквозной проект, где вы соберёте всё изученное в единое портфолио.
