Хочется поговорить о том, что происходит с QA в 2026-м и правда ли, что «нас вот-вот заменит ИИ». Но не в формате очередного треда в духе «всё пропало» или «всё отлично, завтра уволим половину отдела». А по-взрослому: с опытом, цифрами, ограничениями и выводами. То есть попробовать не просто порассуждать, а разобрать тему как небольшое исследование: что реально меняется, где ИИ помогает, а где начинается та самая реальность, которая не влезает в красивую презентацию.
Привет! Меня зовут Оля Шнайдер, я QA-инженер в Авито. В начале этого года я провела исследование рынка QA, чтобы понять, как сейчас работают тестировщики: с чем сталкиваются каждый день, что мешает в работе, а что, наоборот, помогает.
За последние годы роль QA заметно изменилась (или мне так хочется думать). От нас ждут большего — не только непосредственно тестирования и ответственности за результат, но и участия в процессах и много чего ещё. При этом сами процессы не всегда становятся лучше.
Бывали ли у вас ситуации, когда для тестирования нужен сервис, а он ещё не готов, нестабилен или доступ к нему ограничен? В такие моменты на помощь приходят стабы и моки. Один из самых удобных инструментов для этого — WireMock. Он позволяет легко эмулировать работу backend-сервисов, подменяя реальные ответы на заранее подготовленные.
В этой статье я расскажу, как запустить wiremock-standalone.jar, и покажу, почему этот инструмент одинаково полезен как мануальным тестировщикам, так и автоматизаторам.
Метрики — это количественные показатели, которые помогают отслеживать эффективность процесса тестирования и выявлять области для улучшения. Например:
Процент дефектов в критических модулях: Этот показатель помогает понять, насколько стабильны ключевые компоненты приложения, важные для пользователей.
Скорость обнаружения дефектов (Defect Discovery Rate): Оценка того, насколько быстро обнаруживаются баги. Чем быстрее инженер находит дефекты, тем быстрее они могут быть устранены.
Ретесты и регрессии:Читать полностью »
В современной разработке программного обеспечения роли четко распределены: разработчики пишут код, системные аналитики формируют требования, а QA‑инженеры обеспечивают качество. Но что происходит, когда компания решает нарушить это равновесие и нанять опытных разработчиков без QA бэкграунда в отдел тестирования? Наш опыт показал, что это может привести к неожиданным результатам.
2007-й год не вернуть: профессия QA-инженера, которая ещё недавно была престижной и высоко ценилась, сегодня стремительно теряет влияние, превращая опытного эксперта в «универсального бойца», которому можно спихнуть любую работу. Эта статья — моя личная история, в которой я разбираю, почему профессия больше не ценится и что сделать, чтобы она не попала в красную книгу как исчезнувший вид.
На протяжении нескольких лет многие думают о том, как попасть и реализовать себя в IT-сфере, а во времена ковида тренд значительно усилился. И этот вопрос остаётся актуальным до сегодняшнего дня.
Возможно, моя история кого-то вдохновит или покажет, что любая ваша идея может воплотиться в реальность.
Представьте – вы разработчик, и тестировщик приносит баг, который найден в ходе регресса. Хочется поправить этот баг и вы просите оформить тикет. Уже представляете как возьмете его в работу, залинкуете к нему пулл реквесты и проставите эстимейты, чтобы не было вопросов у продакт менеджера.
Меня зовут Ася, я ведущий инженер-тестировщик (QA Lead) в КРОК.
Недавно я отметила десятилетний юбилей в компании и в тестировании одновременно — да, за столько лет мне не надоело ни там, ни там. Хотя насчет тестирования было по-разному — успела даже дважды выгореть (один раз из-за декрета), стать контрол-фриком и влюбиться в профессию заново.
Про профессию тестировщика часто слышу, что это самый легкий и быстрый порог входа в ИТ — а там и на разработчика переучиться можно. Я же наоборот — училась на разработчика и даже успела им немного поработать, но душа к этому не лежала, потому что искать баги намного веселее. За всю мою карьеру я участвовала в совершенно разнообразных проектах: документооборот, файлообменники, статистические наблюдения, обработка обращений пассажиров в ЦППК, учет оборудования. А потом поняла, что этот опыт можно масштабировать на свою жизнь и даже на работу целого департамента. Так я стала агентом изменений департамента разработки программного обеспечения (ДРПО).
В этой статье хочу рассказать про свой путь и постараться ответить на вопрос, который мучает многих тестировщиков — а есть ли жизнь на Марсе задор и челленджи после многих лет в тестировании?
Читать полностью »
Привет! Меня зовут Люба, и я QA инженер команды разработки систем для контакт-центра в Lamoda.
Недавно исполнилось три года, как я работаю в нашей компании, и это заставило меня задуматься и заново посмотреть на события, которые происходили с момента, как я выбрала эту профессию, на решения, которые я принимала. На каком-то этапе своего карьерного пути я столкнулась с выгоранием, и была близка к тому, чтобы совсем уйти из профессии. Но не ушла, а наоборот продолжаю реализовывать себя в этой же сфере, причем работаю уже сравнительно долго на одном месте, и пока не собираюсь уходить.
Читать полностью »
