Инженер
по тестированию

Если человек пока сам не знает, чем хочет заниматься в IT, то тестирование — это хороший способ познакомиться с процессами создания продукта и ролями в команде.

Однако лучше всё же заранее больше узнать про профессии и сразу учиться на то, что больше откликается. Быстрее будет сразу выучиться на разработчика, чем учиться на инженера по тестированию, а потом переходить в разработку.

В ручное тестирование я попала почти 13 лет назад и занималась самыми разными проектами, но в какой‑то момент увидела потолок: сложно построить бесконечный путь развития для ручного тестировщика. Я хотела иметь личную ответственность за свою работу, чтобы результат был понятным и ощутимым. В моей команде появилась вакансия разработчика, и мне предложили попробовать. Я согласилась, и мне понравилось.

Перейти из тестирования в разработку — это долго и морально тяжело. Это ежедневный кропотливый труд, который требует безумного количества времени и сил. То есть недостаточно просто 8 часов работать на работе. Ты работаешь на работе, а потом ещё минимум 4 часа — дома, чтобы стать разработчиком. Может, это легче, чем начинать с нуля, но это точно не легко.

Писать автотесты я научилась в Яндекс Бизнесе. Автоматизация — отличный инструмент в арсенале тестировщика и один из путей развития компетенций. У нас на проекте QA‑инженер совмещает работу ручного тестировщика и автоматизатора. Новые функции мы всегда тестируем вручную, а автотестами проверяем регрессию — не сломалось ли то, что табильно работало до этого.

Команда всегда сама решает, выгодно ли ей использовать автотестирование или эффективнее будет выполнить проверки вручную. Наш проект уже довольно большой: 4 года разработки, и постоянно выкатывается новый функционал. Поэтому для нас отлично работает автоматизированная регрессия — она снимает рутинную нагрузку по проверке работы старого кода, освобождает время на исследовательское тестирование.

Автоматизация в Беспилотных технологиях — это не то же самое, что в других сервисах. Это не про программирование, а больше про аналитические инструменты.

Ручное тестирование у нас — это когда человек накатывает на систему беспилотного автомобиля новую версию кода и проверяет его на дороге, на первом этапе — на нашем испытательном полигоне. Он отмечает, как ведёт себя система, а потом анализирует проезд.

Автоматизированное тестирование — это своего рода симуляция уличного пространства, автомобильного окружения, с какими‑то интересными или важными дорожными ситуациями, которые беспилотный автомобиль встречал в реальности. В этот симулятор мы можем загрузить свежую версию кода, прогнать и посмотреть, как он себя ведёт.

Опытный QA‑инженер всегда будет стараться смотреть на фичу так, как потом на неё будет смотреть пользователь, попытается оценить её место и значимость в общей стратегии развития сервиса. Допустим, сегодня мы находим по 5‑10 багов в релизе, а хотим довести качество задач до того состояния, когда на этапе передачи в тестирование в них уже практически нет ошибок. Что для этого нужно сделать?

Высокоуровневый тестировщик может посмотреть на продукт раньше со своей экспертизой и опытом. Мы можем начинать тестировать продукт на этапе дизайна, проектирования идеи, составления кейсов и сценариев для разработчика, то есть ещё до того, как он начал разрабатывать задачу. Тогда на выходе у нас станет существенно меньше ошибок в реализации кода.

Нужно мыслить стратегически, не просто решать задачу, а думать про процесс. Когда тестировщик думает о том, «как сделать так, чтобы не»‎ — не допустить ошибок в будущем, не тратить время на рутинный регресс и не тестировать лишнее, то начинается рост — личный и командный.