Существует стереотип, что тестирование  — это «лёгкий вход в IT» или скучная проверка того, что и так должно работать. Но когда твой продукт высоконагруженная СУБД, которая отвечает за данные банков и корпораций, цена пропущенного бага — не просто «ой, кнопка поехала», а остановка бизнеса.

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

Чем занимается QA-инженер

Часто говорят, что мы просто проверяем работу за разработчиками. Это поверхностный взгляд. Задача QA — не просто убедиться, что код работает, а найти сценарии, где он сломается. Мы должны думать не как создатели системы, а как пользователи, которые обязательно нажмут не туда.

Миф о рутине тоже живёт долго. Да, регрессы существуют. Но если загнать инженера в жёсткие рамки чек-листов, вы получите пропущенные баги. Хороший QA не ходит по шаблону — он исследует продукт и ищет новые грани (и новые способы его уронить), о которых никто не подумал при планировании.

Как я пришла в QA

После школы я хотела быть учителем и поступила в педагогический вуз, на специальность «Информатика и английский язык». После выпуска поняла, что мне близка сфера IT, и тут английский язык помог в дальнейшем погружении.

После выпуска у тебя ещё нет хард-скилов, и одна из самых простых точек входа в IT — QA-инжиниринг. Плюс мне нравилось копаться в деталях, находить проблемы и способы их решения, даже если на это требуется много времени. Как раз то, что нужно для QA.

Как стать настоящим QA-инженером и развиваться в профессии

В вузе тестирование обычно изучается в рамках программирования, и этого достаточно, чтобы узнать основы и понять, интересно ли вам это. Далее можно погружаться самостоятельно или проходить курсы. 

Сегодняшний стандарт для серьёзного QA — это уверенное владение Python как самым гибким инструментом автоматизации и глубокое понимание Linux. Особенно в системной разработке: ты не сможешь качественно протестировать сложный продукт, если боишься консоли или не понимаешь, как работает окружение.

Но хард-скилы сами по себе только инструменты. Главные софт-скилы QA — системное мышление и умение аргументировать. Мало найти баг, нужно уметь «продать» необходимость исправить его разработчику. Это не про «избегание конфликтов», а про конструктивный диалог на одном техническом языке.

Куда расти?

1. Технический трек (QA Architect/Lead SDET). Бесконечное углубление в код, архитектуру тестов и CI/CD. Вы становитесь экспертом, который может построить инфраструктуру качества с нуля.

2. Менеджерский трек (Team Lead/Head of QA). Фокус смещается на процессы, наём и менторство. Иллюзия, что менеджеру не нужны глубокие технические знания, опасна: чтобы управлять командой инженеров, нужно понимать их боли и сложность задач.

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

Как у нас: задачи и подходы 

В Postgres Professional есть и направление QA (quality assurance), и направление QC (quality control): мы подходим к тестированию комплексно. Мало просто проверять качество выпускаемого продукта — важно также контролировать качество, постоянно анализировать, как можно сделать продукт лучше.

Наши задачи делятся на два больших стрима:

1. Работа с исправлениями (Bugfix & Regression).
   Мало подтвердить, что разработчик исправил баг. Наша цель — убедиться, что он не воскреснет через месяц. Поэтому любой критичный фикс должен покрываться регрессионным тестом. Это «страховка» от деградации продукта.

2. Тестирование новых фич (Feature Testing).
   Работа начинается задолго до билда. Мы изучаем документацию и требования, чтобы понять не только как фича должна работать, но и как она может сломать соседние компоненты. В зависимости от сложности выбираем инструмент: от простых чек-листов до полноценных тест-кейсов и немедленной автоматизации.

Мы стремимся к 100%-й автоматизации, но смотрим на вещи реально. Покрытие в разных модулях отличается: легаси-код или экспериментальные фичи требуют разного подхода. Где-то достаточно юнит-тестов от разработчиков, а где-то QA должен обложить функциональность сложными интеграционными сценариями.

Что такое хороший QA и как его выстроить 

Хорошими мы называем стабильные QA-тесты, которые достаточно полно покрывают фичу или продукт.

Важно, чтобы департаменты выпуска и разработки активно взаимодействовали: например, при передаче продукта в департамент разработки наш департамент выпуска предоставляет отчёты о том, что и как было протестировано, даёт рекомендации по улучшению покрытия и качества продукта в целом.

Ещё мы стараемся, чтобы параллельно с кодом сразу создавались тесты. Например, разработчики пишут TAP-тесты — функциональные тесты Postgres, или юнит-тесты для Go. Одновременно QA-инженеры готовятся к тестированию готового продукта: анализируют документацию, общаются с бизнес-аналитиками и техническими менеджерами продукта. На основе полученной информации специалисты составляют тест-кейсы и чек-листы, автоматизируют их и включают в CI.

Хорошо, когда есть DevOps-инженер, который разгружает QA. Если его нет, это тоже ложится на QA-инженера.

Ручное vs автоматизированное тестированиеАвтоматизация очень помогает для рутинных задач, где при ручной перепроверке замыливается глаз. В данном случае автотесты только повысят качество тестирования и исключат ошибки, связанные с человеческим фактором.

Исследовательское ручное тестирование дополняет автотесты и помогает обнаружить особенности продукта, корнер-кейсы, которые автоматизация не покрывает.

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

Например, однажды я решила поднять кластер нестандартным способом, пропустив один шаг, и произошёл отказ системы. Пользователь может пойти своим путём, а разработчик этого не предусмотрел.

С точки зрения исследовательского тестирования в Postgres есть свои инструменты для фаззинга и составления рандомных комбинаций, в частности наша внутренняя разработка, комбинатор, которая перемешивает файлы с запросами в SQL-файлах.

ASAN и Valgrind используем для поиска утечек памяти и профилирования, для ручного тестирования веб-приложений — Selenium и Selenoid, для автотестов — Pytest и Allure TestOps в качестве TMS.

Ванильный PostgreSQL vs коммерческий код: в чём разница для QA

Наша СУБД основана на ванильной версии PostgreSQL, и это накладывает отпечаток на процессы. Мы не просто забираем код — мы его чистим.

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

То же касается расширений: перед добавлением любого внешнего компонента мы проводим жёсткое исследовательское тестирование. Найденные баги отправляются авторам. Мы добавляем компонент к себе только после фикса и стабилизации.

Почему ванильные баги — это боль

Отлавливать и чинить баги в апстриме сложнее, чем в собственном коде.

• Проблема бисекции. В коммерческом коде, который пишется у нас, мы видим каждый коммит. Если что-то сломалось, git bisect быстро укажет на виновника. С ванилой сложнее: мы подтягиваем изменения из апстрима пакетами. Если после очередного мержа что-то отвалилось, приходится анализировать огромный массив чужих изменений, чтобы найти причину.

• Коммуникация. С коммерческим кодом проще: команда разработки сидит в соседнем кабинете (или чате). Можно быстро спросить, получить фикс и проверить. С сообществом цикл обратной связи всегда длиннее.

ИИ и вайб-кодинг: хайп или польза?

Сейчас модно говорить про вайб-кодинг: когда ты описываешь задачу ИИ, а он пишет код за тебя. В QA это работает, но с оговорками.

Мы используем ИИ-инструменты для генерации наборов простых тест-кейсов (например, в Pairwise) или для написания несложных вспомогательных скриптов. Это снимает с инженера рутину «чистого листа».

Но важно понимать границу. ИИ — это джуниор, который никогда не устаёт, но часто галлюцинирует. Он неспособен предусмотреть глубокие архитектурные особенности продукта или неочевидные корнер-кейсы. С определённого этапа всегда должен подключаться человек, иначе вайб закончится критическим багом на проде.

Полезные ресурсы

Небольшой список того, что поможет начать изучение QA и быть в курсе всего важного: 

• «Тестирование Дот Ком» Романа Савина. В своё время эта книжка дала мне полное представление о том, что такое тестирование и как начать.

• «Как тестируют в Google» Джеймса Уиттакера, Джейсона Арбона и Джеффа Кароло — интересные концепции того, как ещё может строиться тестирование.

• «Серьёзный тестировщик» — телеграм-канал на 13 тысяч подписчиков, бывают интересные темы.

• Heisenbug и SQA Days — конференции с классными докладами.

Вместо заключения

В нашей профессии нужно много терпения и сосредоточенности, но одинаково важно уметь переключаться. Иногда это и помогает решить проблему спустя неделю безрезультатной ловли какого-нибудь флакающего бага.

По моему опыту — решение всегда найдётся. Не забывайте про физическую активность и всё, что позволяет мозгу отвлечься. Это даёт силы вернуться к задаче и посмотреть на неё с новой стороны.