Интернет развивается с бешеной скоростью — новых сайтов и приложений становится все больше, а вместе с ними растет и количество багов. По статистике, 70% веб-ресурсов ломаются в какой-то момент. И для того, чтобы все работало исправно, нужно как можно больше грамотных QA-инженеров. Мы поговорили с одним из них — Михаилом Шептуном о том, зачем нужно тестирование, вытеснит ли ИИ специалистов и, какие ошибки допускают новички.
«Я пошел в тестировщики, потому что хотел знать, как работает система изнутри. Мне нравится находить слабые места в продукте и делать его лучше», — делится Михаил в начале беседы.
— Михаил, вы уже восемь лет в тестировании. Как за это время изменилась сфера?
— Кардинально. Бизнес пересмотрел свое отношение к тестированию, так как ошибки в системе напрямую бьют по их карманам. Сейчас практически все компании работают через интернет. Если сайт зависает или плохо работает, то клиенты не будут тратить время и уйдут к конкурентам. По данным Quality Hive, бизнес теряет в среднем 4% годового дохода из-за багов на своих веб-ресурсах. Для крупных компаний это миллионы долларов.
Поэтому сейчас в тестировании самое главное — стабильность и скорость. Инструменты вроде Cypress, Playwright и testContainers помогают писать тесты быстрее. Фокус сместился на устранение нестабильных тестов, параллельное выполнение и оптимизацию CI.
— Получается, поменялась и роль тестировщика?
— Да, теперь это QA-инженер. То есть специалист, который отвечает за качество, а не просто человек, который исправляет ошибки в программном обеспечении и выслеживает их. Мы участвуем в подготовке технического задания к ПО и code review, разрабатываем план тестирования, вовлечены в CI/CD, работаем с контейнерами, API, обучаем джунов…
Раньше тестировщиков привлекали как сторонних специалистов, сейчас компании стараются держать в штате хотя бы одного инженера по качеству.
— С чем вы это связываете?
— ИТ-стартапов становится больше. Они сначала выпускают MVP, а потом дорабатывают его с учетом полученных откликов. Это может быть и нейросеть для диагностики рака, и мобильное приложение для документооборота внештатников, и просто интернет-магазин. Всем им важно удержать первых клиентов, привлекать новых, одновременно с этим улучшать свой продукт. И баги для них просто недопустимы. Особенно, когда речь идет о медицине или банковской сфере. Поэтому в штате нужны специалисты по качеству, которые будут видеть картину целиком и исправлять то, что не работает как надо.
Чем больше технических проектов, тем больше тестировщиков нужно, чтобы следить за их качеством.
— Разве нельзя все автоматизировать?
— Автоматизация не может полностью заменить ручное тестирование. Да, автотесты работают быстрее ручных: их можно запускать параллельно, проверять сотни сценариев и легко интегрировать в CI/CD. Но какой бы продвинутой ни была машина, она не понимает контекст и не может предугадать, как поведет себя пользователь. К примеру, автотесты проверяют работает ли приложение авиакомпании, отправляет ли вовремя уведомления о задержке рейса, не зависла ли оплата. Но они не знают, привлекательна ли цветовая гамма, не сливается ли надпись «Оплатить» с фоном и вообще удобно ли пользоваться этим приложением. Такое заметит только человек.
В целом, когда приложение постоянно обновляется и надо проверять UIX, дизайн и нестандартные сценарии, то лучше делать это в ручном режиме. А автоматизация выгодна при частных релизах.
— Искусственный интеллект влияет на тестирование?
— Его применяют при создании тестов на основе анализа кода и поведения пользователя. Например Testim, Mabl, Launchable. ИИ может анализировать, почему упал тест, выделяет логи, ошибки в коде, а также помогает написать автотесты быстрее. Со временем его влияние будет расширяться. Но искусственный интеллект, нейросети — лишь помощники. Они не умеют критически мыслить, оценивать достоверность сгенерированных данных и, поэтому, ИИ тоже не сможет полностью вытеснить ручное тестирование.
— В Linkedin сказано, что вы ускорили выполнение тестов на 20%. Расскажите, как вам это удалось? Думаю, новичкам будет интересно.
— Я оптимизировал автотесты на Cypress и Playwright за счет внедрения параллельного запуска, mock API данных и устранения избыточных ожиданий. В Playwright каждый файл теста запускается в отдельном воркере. В Cypress я настроил параллельное выполнение через CI/CD, Dashboard и CLI-флаг.
Во-вторых, устранил дублирование кода, используя hooks и DRY. Также я использовал мокирование API-запросов, чтобы эмулировать ответы сервера без реального взаимодействия с бэкендом. Перевел тесты в headless-режим, чтобы запускать браузер без графического интерфейса и снизить нагрузку на систему.
А для того, чтобы сократить задержки, отказался от явного использования таймаутов, так как в Playwright и Cypress уже встроены механизмы автоматического ожидания. Для ускорения работы CI/CD я внедрил кеширование, а тестовую среду изолировал с помощью Docker.
— Каким своим профессиональным достижением вы гордитесь больше всего?
— За эти восемь лет было много интересных проектов. Но технически сложным было, когда я взялся восстановить автотесты для устаревшего продукта в сфере медицины. В команде никто не знал, как работает тестовый фреймворк на Selenium, и пришлось полностью переписывать все на Cypress. Я изучил бизнес-логику, разобрался в коде, воссоздал логику тестов, устранил баги, внедрил k6 для нагрузочного тестирования. В итоге проект, который считался мертвым, снова стал частью CI/CD. Пожалуй, этим горжусь больше всего.
— А какие ошибки чаще всего совершают джуны?
— Пытаются усложнить код, вместо того чтобы сделать проще. Не продумывают структуру проекта, не используют Page Object Model. Новички часто используют `wait(5000)`, из-за чего тесты проходят медленно и нестабильно. Или плохо валидируют результаты — проверяют, что кнопка нажалась, но не смотрят, что случилось дальше.
— Какие навыки нужны, чтобы стать востребованным инженером по тестированию?
— Нужно знать, какие виды тестирования есть, как и когда их применять. К примеру, Cypress и Playwright используются для автоматизации UI-тестов на JavaScript/TypeScript, а Postman — для тестирования API вручную. Необходимо разбираться в архитектуре автотестов, включая принципы POM, DRY и построении хорошо структурированного кода.
Но одних только технических навыков недостаточно. Нужно уметь общаться, выступать с презентациями, обладать аналитическим складом ума и критически мыслить.
— Михаил, в завершение беседы хочу спросить, каким вы видите будущее тестирования?
— Технологии стремительно развиваются, а вместе с ними усложняются и системы. За одним только мобильным приложением стоят облачные серверы, базы данных, ИИ, интеграция с другими сервисами — и все это должно работать как единое целое. Компании уже конкурируют друг с другом в цифровизации и со временем эта гонка только ускорится. Чтобы одержать первенство, нужно, чтобы их ИТ-продукты работали быстро и без ошибок. Значит, у тестировщиков прибавится работы. Я с огромным интересом жду этого момента.
Спасибо Вам за интересную и содержательную беседу.
Автор: Евгения Лебедева