Существует стереотип, что тестирование — это «лёгкий вход в IT» или скучная проверка того, что и так должно работать. Но когда твой продукт высоконагруженная СУБД, которая отвечает за данные банков и корпораций, цена пропущенного бага — не просто «ой, кнопка поехала», а остановка бизнеса.
Руководитель отдела тестирования и контроля качества Postgres Professional Юлия Рынденкова рассказывает, почему хороший QA-инженер обязан быть душнилой, как ломать кластеры способами, которые не снились разработчикам, и что на самом деле происходит под капотом тестирования одной из самых популярных баз данных в мире.
Чем занимается QA-инженер
Часто говорят, что мы просто проверяем работу за разработчиками. Это поверхностный взгляд. Задача QA — не просто убедиться, что код работает, а найти сценарии, где он сломается. Мы должны думать не как создатели системы, а как пользователи, которые обязательно нажмут не туда.
Миф о рутине тоже живёт долго. Да, регрессы существуют. Но если загнать инженера в жёсткие рамки чек-листов, вы получите пропущенные баги. Хороший QA не ходит по шаблону — он исследует продукт и ищет новые грани (и новые способы его уронить), о которых никто не подумал при планировании.
Как я пришла в QA
После школы я хотела быть учителем и поступила в педагогический вуз, на специальность «Информатика и английский язык». После выпуска поняла, что мне близка сфера IT, и тут английский язык помог в дальнейшем погружении.
После выпуска у тебя ещё нет хард-скилов, и одна из самых простых точек входа в IT — QA-инжиниринг. Плюс мне нравилось копаться в деталях, находить проблемы и способы их решения, даже если на это требуется много времени. Как раз то, что нужно для QA.
Как стать настоящим QA-инженером и развиваться в профессии
В вузе тестирование обычно изучается в рамках программирования, и этого достаточно, чтобы узнать основы и понять, интересно ли вам это. Далее можно погружаться самостоятельно или проходить курсы.
Сегодняшний стандарт для серьёзного QA — это уверенное владение Python как самым гибким инструментом автоматизации и глубокое понимание Linux. Особенно в системной разработке: ты не сможешь качественно протестировать сложный продукт, если боишься консоли или не понимаешь, как работает окружение.
Но хард-скилы сами по себе только инструменты. Главные софт-скилы QA — системное мышление и умение аргументировать. Мало найти баг, нужно уметь «продать» необходимость исправить его разработчику. Это не про «избегание конфликтов», а про конструктивный диалог на одном техническом языке.
Куда расти?
- Технический трек (QA Architect/Lead SDET). Бесконечное углубление в код, архитектуру тестов и CI/CD. Вы становитесь экспертом, который может построить инфраструктуру качества с нуля.
- Менеджерский трек (Team Lead/Head of QA). Фокус смещается на процессы, наём и менторство. Иллюзия, что менеджеру не нужны глубокие технические знания, опасна: чтобы управлять командой инженеров, нужно понимать их боли и сложность задач.
И да, иногда из QA уходят в разработку или аналитику. Опыт тестирования там работает как суперсила: такие разработчики пишут более чистый код, потому что заранее видят, где он может сломаться.
Как у нас: задачи и подходы
В Postgres Professional есть и направление QA (quality assurance), и направление QC (quality control): мы подходим к тестированию комплексно. Мало просто проверять качество выпускаемого продукта — важно также контролировать качество, постоянно анализировать, как можно сделать продукт лучше.
Наши задачи делятся на два больших стрима:
- Работа с исправлениями (Bugfix & Regression).
Мало подтвердить, что разработчик исправил баг. Наша цель — убедиться, что он не воскреснет через месяц. Поэтому любой критичный фикс должен покрываться регрессионным тестом. Это «страховка» от деградации продукта. - Тестирование новых фич (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 — конференции с классными докладами.
Вместо заключения
В нашей профессии нужно много терпения и сосредоточенности, но одинаково важно уметь переключаться. Иногда это и помогает решить проблему спустя неделю безрезультатной ловли какого-нибудь флакающего бага.
По моему опыту — решение всегда найдётся. Не забывайте про физическую активность и всё, что позволяет мозгу отвлечься. Это даёт силы вернуться к задаче и посмотреть на неё с новой стороны.
В серии рассказов о специалистах, работающих в Postgres Professional, также есть статьи о: