Весь курс вы выполняли проверки вручную — по тест-кейсам (глава 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).
Подсказка: Вспомни определение исследовательского тестирования из главы 10 — чем оно принципиально отличается от выполнения заранее заданных шагов.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Задание. Команда обсуждает, какие из четырёх проверок автоматизировать в первую очередь при ограниченном бюджете: (1) регрессионный набор из 50 проверок API оплаты курса, гоняется перед каждым релизом уже год; (2) разовая сверка данных после миграции базы, которая больше не повторится; (3) юзабилити-оценка нового экрана оформления заказа; (4) проверка API каталога курсов (глава 8), стабильная уже полгода, тоже часть регресса. Распредели все четыре проверки по приоритету автоматизации (от «точно автоматизировать» до «не автоматизировать вовсе») и обоснуй порядок, опираясь на пирамиду и ROI из этого урока.
Критерий приёмки: проверки (1) и (4) отнесены к «точно автоматизировать в первую очередь» — оба API-уровня пирамиды, оба регрессионные и стабильные, высокий ROI; проверка (2) отнесена к «не автоматизировать» — разовая задача, ROI не окупится; проверка (3) отнесена к «не автоматизировать» — юзабилити требует человеческого суждения, а не технической проверки; обоснование явно опирается на ROI (частота повторения) и/или на уровень пирамиды, а не на произвольные предпочтения.
Подсказка: Для каждой из четырёх проверок отдельно ответь на два вопроса: как часто она повторяется (ROI) и требует ли она человеческого суждения (юзабилити vs API/регресс).
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Что дальше
Мы разобрали, как решить, что стоит автоматизировать, а что нет, и чем занимается automation QA — без единой строчки кода, это отдельная тема продвинутого курса. Это был обзорный мост между ручным тестированием и автоматизацией — дальше в курсе сквозной проект, где вы соберёте всё изученное в единое портфолио.
