Senior QA Engineer Стас: о скрытых деталях работы тестировщика

АйТиБорода 796 тыс. 1 ч 5 мин 7 мин 30.08.2018
Главное

В новом интервью на канале АйТиБорода популярный ведущий общается с опытным специалистом в сфере обеспечения качества программного обеспечения. Гость встречи, Senior QA Engineer Стас, делится своим пятилетним опытом работы в индустрии, рассказывает о внутренней кухне профессии и развенчивает популярные мифы. В фокусе обсуждения — разница между тестированием и контролем качества, карьерный путь новичка, особенности суровых технических собеседований и будущее ручного тестирования в эпоху автоматизации.

🚪 Путь в профессию: из студентов в Senior QA 1:03

Карьера Стаса в сфере обеспечения качества началась неожиданно, когда он учился на 3–4 курсе Академии управления при Президенте Республики Беларусь. Представители крупной IT-компании iTransition пришли в университет с презентацией профессии тестировщика и пригласили студентов на экскурсию. На тот момент будущий инженер, по его собственному признанию, ничего не знал о тестировании.

Стас успешно прошел отбор, честно заявив на интервью о своем нулевом уровне знаний, и получил работу. В структуре iTransition он проработал около пяти лет, застав этап, когда из нее выделилась крупная специализированная компания a1qa (в транскрипте фонетически искажено как «Валкейн»/«Ван Кей»). На момент записи интервью Стас сменил место работы и перешел в компанию SoftSwiss.

🔍 Кто такой тестировщик: обязанности и специфика 2:54

Понятие «тестировщик» часто ассоциируется исключительно с поиском ошибок, однако круг обязанностей инженера по качеству гораздо шире. Стас подробно описывает ключевые задачи специалиста на проекте:

Ручное и автоматизированное тестирование

По словам гостя, начальный этап в профессии чаще всего связан с мануальным (ручным) тестированием, когда все проверки выполняются специалистом вручную. Автоматизированное тестирование предполагает написание программного кода для автоматического запуска тест-сценариев специальными программами.

Стас отмечает, что переход из ручного тестирования в автоматизацию является распространенной и естественной практикой для тех, кто хочет развивать навыки программирования. По его мнению, ручное тестирование также может служить отличным промежуточным этапом для тех, кто изначально хотел стать разработчиком, но на старте не добрал нужного объема технических знаний.

📐 Пирамида качества: разница между QA, QC и тестированием 6:40

В индустрии часто путают понятия Quality Assurance (QA), Quality Control (QC) и непосредственно тестирование. Стас предлагает четкую иерархию этих терминов:

Гость подчеркивает, что ключевое отличие заключается в векторе внимания: QC сфокусирован на качестве готового продукта, тогда как QA — на качестве самих процессов разработки. Соответственно, позиция QA-инженера требует значительно большего опыта, так как включает в себя QC как один из составных этапов.

📊 Градация специалистов в QA: от Junior до Senior 9:21

Иерархия уровней в тестировании во многом совпадает с разработкой, хотя критерии могут варьироваться в зависимости от корпоративной этики конкретной компании. Традиционно на рынке выделяют три основные ступени по времени работы:

  1. Junior QA Engineer — специалист с опытом до одного года, обладающий базовой теоретической подготовкой. На него не возлагают сложные задачи вроде самостоятельной оценки рисков проекта.
  2. Middle QA Engineer — инженер с опытом от одного года до трех лет, способный работать без постоянного контроля, вести митинги и напрямую общаться с заказчиком.
  3. Senior QA Engineer — специалист с опытом работы более трех лет, формирующий стратегию тестирования, настраивающий процессы с нуля и управляющий командой.

🛠 Рабочие будни и взаимодействие с разработчиками 11:35

Типичный рабочий день QA-инженера начинается с проверки актуальных задач и баг-трекинговых систем (Jira, Skype, почта). Значительную часть времени занимает составление и актуализация тест-кейсов — документов, описывающих сценарии проверок, которые видит вся команда. Важным процессом является перепроверка исправленных разработчиками багов (reopen/close активности).

Проблема общих тест-кейсов и конфликты

Вопрос о том, стоит ли открывать тест-кейсы разработчикам, остается дискуссионным. Стас объясняет, что в сложных системах это полезно: разработчики могут подсказать скрытые нюансы архитектуры. Однако на простых проектах гость не рекомендует делиться сценариями, так как недобросовестные разработчики могут намеренно писать код исключительно «под тесты», упуская другие критические сценарии.

Гость подчеркивает, что за качество итогового продукта отвечает абсолютно вся команда, а не только отдел тестирования. На вопрос АйТиБороды о том, кто важнее — программист или тестировщик, Стас отвечает, что все роли на проекте равноценны, и разработка не может эффективно существовать без контроля качества. При этом тестировщики обычно не касаются написания юнит-тестов (unit-тестов), так как это сугубо зона ответственности разработчиков для проверки грамотности своего кода.

Идеальный разработчик глазами QA

По мнению Стаса, идеальный коллега-разработчик должен обладать следующими качествами:

При этом количество багов в коде, как считает гость, не влияет на личное отношение к программисту, если ошибки не вызваны элементарной халатностью (например, когда фича вообще не запускается на базовом уровне).

📈 Метрики, процессы и документация 27:30

Внутри команд регулярно собирается статистика для оценки эффективности процессов. К основным метрикам качества разработки относятся:

Процессы улучшения тестирования включают проведение код-ревью для тест-кейсов (когда тестировщики проверяют документацию друг друга) и написание подробных гайдов по приложению. В среднем работа с документацией занимает около 30% всего рабочего времени специалиста.

🗣 Английский язык и суровые собеседования 31:55

Уровень владения английским языком в тестировании зачастую требуется выше, чем в разработке, поскольку QA-инженеры постоянно работают с англоязычными требованиями, ведут переписку и участвуют в созвонах с иностранными заказчиками.

Рассказывая о своем опыте прохождения около 15 собеседований, Стас описывает случай из практики, когда техническое интервью длилось 2,5 часа. На нем проверяли не только теорию тестирования, но и глубокие технические знания: основы сетей (IP-адреса, маски подсетей) и написание сложных SQL-запросов к базам данных.

Вторым этапом стала полуторачасовая беседа с техническим директором, предложившим абстрактный логический кейс:

Представь, что ты архитектор-проектировщик во времена Юлия Цезаря. Твоя задача — спроектировать Колизей так, чтобы он был максимально посещаемым, безопасным и удобным для проведения масштабных зрелищ.

🚀 Как войти в IT через тестирование: советы новичкам 40:40

На текущий момент рынок перенасыщен специалистами уровня Junior из-за обилия коммерческих курсов, обещающих легкий вход в IT. Многие выпускники остаются без работы из-за нехватки практического опыта. Стас рекомендует начинающим практиковаться на специализированных фриланс-платформах для тестировщиков, чтобы наработать портфолио.

Для самостоятельного изучения гость советует обратить внимание на профильную литературу:

Однако Стас предупреждает, что сухой теории из книг недостаточно. По его мнению, идеальный баланс при обучении должен составлять 70% практики и 30% теории, поэтому стоит выбирать курсы с максимальным упором на реальные проекты.

⚡ Блиц-опрос и мифы о QA 49:48

В завершение беседы Стас ответил на острые вопросы ведущего АйТиБорода и подписчиков канала:

По мнению Стаса, главными качествами идеального тестировщика являются внимательность, коммуникабельность, тактичность и искреннее желание сделать продукт лучше.

💬 Цитаты

«За качество продукта отвечает вся команда. Разработчики разрабатывали — они сделали ошибку, то что тестировщики не нашли ошибку — это тоже плохо.»

«Автоматизация не сможет полностью заменить ручное тестирование. В любом случае будет существовать симбиоз.»

👥 Спикеры
📚 Упомянутые книги
🔗 Упомянутые сайты и проекты
📖 Термины
Quality Assurance (QA)
Обеспечение качества процессов разработки для предотвращения появления дефектов.
Quality Control (QC)
Контроль качества готового продукта на соответствие заявленным требованиям.
Тест-кейс (Test Case)
Документ, описывающий последовательность шагов для проверки определенной функции приложения.
Юнит-тест (Unit Test)
Тест для проверки минимальной изолированной части кода, выполняемый разработчиками.
📊 Цифры
🗓 Хронология
  1. 3-4 курс университета Стас узнает о профессии тестировщика от представителей iTransition и проходит отбор.
  2. После 3 лет работы Продление контракта в компании с переходом к обучению сотрудников и менторству.
  3. Через 5 лет Переход Стаса из компании a1qa в SoftSwiss на позицию Senior QA Engineer.
⚖️ Другая сторона
Технологии и IT Quality Assurance Тестирование ПО АйТиБорода SoftSwiss