
Представим ситуацию. 2010 год, вы сидите за компьютером и играете в Counter Strike или Call of Duty. В самый ответственный момент игра начинает подвисать или вы застреваете в текстурах, из‑за чего сливаете миссию. Обидно, но такое бывает по 10 раз в день, поэтому вы смиренно начинаете снова. А теперь представим ту же ситуацию в 2025 году. Очевидно, что сейчас большинство пользователей, столкнувшись с нерешаемой проблемой в игре, в итоге просто забросят ее. Потому что паттерны людей и их требования к продукту меняются. Соответственно, должны меняться и подходы к обеспечению качества ИТ‑продуктов.
Меня зовут Алексей Петров. Я директор по качеству в ОК. В этой статье я в легкой исторической перспективе рассмотрю основные тренды и подходы, которые использовались в недавнем прошлом и актуальны сейчас.
Основные тренды качества сегодня
Вопрос обеспечения качества выпускаемых ИТ‑продуктов стал актуальным не сейчас — им занимаются давно. Но паттерны, инструменты и подходы развивались постепенно. Фактически то, что мы имеем сейчас — результат длительного пути, на заре которого полноценно заботиться о качестве продуктов могли только крупные компании, у которых были нужные ресурсы и компетенции.
Сейчас подходы и требования к обеспечению качества и QA‑специалистам изменились. Причем изменения комплексно затронули всё. Рассмотрим основные направления — от отношения к качеству до инструментов и автоматизации.
Отношение к качеству

Раньше качество продукта не было самоцелью и критически значимым условием для его релиза.
-
Проверки преимущественно сводились к простому приемочному тестированию, зачастую уже перед релизом в прод. О критическом взгляде на процессы доставки и поиске точек улучшения приложений думали редко или не думали вообще.
-
Качество было значимым только для больших компаний и/или там, где от качества ПО зависели финансовые показатели. При этом многие малые/средние компании занимались тестированием только формально — для «галочки» и успокоения клиентов.
-
Обеспечению качества уделялось мало внимания, поскольку большинство компаний не понимало его бизнес‑ценности, степень влияния на продукт для конечного пользователя и рентабельность нужных ресурсозатрат.
Сейчас ситуация кардинально изменилась в лучшую сторону.
-
На смену простому контролю и тестированию пришел комплексный контроль качества разрабатываемого продукта с применением разных техник (shift‑left testing, shift‑right testing и других).
-
Компании думают не о простой проверке базовых сценариев, а об упреждении появления ошибок и поиске точек роста продукта.
-
Тестирование больше не является прерогативой исключительно крупного бизнеса и активно применяется компаниями разного масштаба, причем независимо от профиля выпускаемого продукта (тестируют как игры, так и веб‑сервисы). Примечательно, что об обеспечении качества думают даже компании, которые еще не выкатили свои проекты в прод.
-
Пришло всеобщее понимание, что качество вносит весомый вклад в позиционирование продукта, влияет на продуктовые, технические и бизнесовые метрики, сказывается на образе компании в целом.
Специалисты

На фоне глобального пересмотра подходов к обеспечению качества изменились и требования к специалистам. Изначально всё было довольно просто.
-
В тестировании были востребованы даже junior‑специалисты без знаний. Для трудоустройства на работу было достаточно понимания основ и изучения профильной литературы. Часто первые практические навыки работы тестировщики получали уже в реальных проектах.
-
Специалисты уровня middle+ были в сильном дефиците, поэтому конкуренция за них была серьезная. Соответственно, такие кадры были преимущественно в крупных компаниях, которые могли предложить достойные условия.
-
Soft skills не имели определяющего значения, поскольку доминировала сервисная модель построения команды с одним ответственным руководителем. То есть, если тестировщик хорошо делает свою работу, но не может отстоять точку зрения и повлиять на релиз — это не являлось критичной проблемой.
-
Наблюдалось преимущественно выраженное профилирование специалистов, при котором у каждого тестировщика была строго определенная зона ответственности.
Сейчас обстоятельства изменились.
-
Требования к Junior стали значительно выше — «корочки» о прохождении курсов и беглого изучения нескольких книг по тестированию уже недостаточно. Нужны реальные знания и практические навыки, потому что возможностей «учить с нуля» в отлаженных бизнес‑процессах остается всё меньше.
-
Специалисты уровня Middle+ востребованы на рынке повсеместно, а не только в крупных компаниях. Обусловлено это тем, что выросли требования к качеству выпускаемых приложений — ИТ‑продукты изначально должны быть стабильными, отказоустойчивыми, удобными.
-
В цене сейчас кроссфункциональные специалисты, которые имеют прокачанную компетенцию минимум по нескольким направлениям, опыт ручного тестирования и автоматизации. Например, в продуктовой команде тестирования ОК все специалисты умеют тестировать на пяти платформах и занимаются автоматизацией тестов минимум для одной из них. И фактически это базовые требования.
-
Soft Skills стали крайне важны при выборе сотрудника. Поскольку сейчас тестировщики часто становятся частью кросс‑функциональных команд, им приходится принимать решение о допустимости выкатки фичи в прод и уметь аргументировать и отстаивать свою позицию перед большой командой. Безусловно, Soft Skills не доминируют над Hard Skills, но тоже имеют большое значение.
Методология

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

В контексте выстраивания процессов на заре становления QA изначально также было все на базовом уровне, что обуславливалось недостаточным пониманием, какие именно методы позволяют обеспечивать качество продукта.
-
Основным подходом к разработке в большинстве компаний был Waterfall, при котором каждый новый этап работы начинается только после того, как команда полностью завершила предыдущий.
-
Новые релизы и обновления выкатывались сразу на всю аудиторию без предварительной проверки на фокус‑группах.
-
Бета‑тестирование встречалось редко, преимущественно в играх.
-
Не было прозрачных процессов эскалации пользовательских инцидентов. Встречались ситуации, когда запросы пользователей на решение тех или иных проблем просто терялись или не брались во внимание, то есть не доходили до команды разработки.
-
Не было внятного мониторинга за продуктовыми/техническими метриками. Фактически фичи запускались, а данные об их работе и влиянии на метрики анализировались только спустя установленный период (например, через месяц, квартал или даже год), а не в реальном времени.
По мере развития QA и повышения требований к качеству ИТ‑продуктов со стороны пользователей, подходы к построению процессов изменились.
-
На смену каскадному подходу Waterfall пришли Agile, Git Flow и другие, более продвинутые варианты, которые позволяют работать более гибко и производительно.
-
Любые релизы сначала проверяются на небольшой аудитории, обязательно проводятся A/B‑тесты, внедряется парадигма Data Driven Development. Это дает возможность лучше учитывать реальные запросы пользователей и без издержек откатываться, если обновление оказалось «сырым» или негативно влияет на бизнес‑метрики.
-
Бета‑тестирование все чаще встречается в продуктовых компаниях. Оно особенно важно, когда нужно получить обратную связь о продукте еще до того, когда он будет готов даже к А/В‑тестированию. Это помогает отлавливать баги и находить точки роста на более ранних этапах разработки.
-
Инцидент‑менеджмент и интеграция с технической поддержкой стали широко распространенной практикой. Благодаря этому бизнес получил возможность оперативно реагировать на жалобы пользователей, приоритизировать запросы и фокусироваться на разработке функций, которых пользователи ждут больше.
-
Мониторинг продуктовых и технических метрик — must have. Сейчас запуски без отслеживания всех метрик и процессов — архаичное исключение, которое практически не встречается.
Инструменты

Теперь о том, к каким изменениям на уровне инструментов привело развитие QA.
-
Изначально компании преимущественно отдавали предпочтение ненативным автотестам и интеграционным автотестам. Причем запуск автотестов был, как правило, ручной.
-
Параллелизации автотестов не было или она встречалась редко. Но отчасти это было допустимо, поскольку автотестов было мало.
-
Отчеты по автотестам делались практически «на коленке» и не всегда отображали всю картину происходящего.
-
Нередко использовался целый «зоопарк» инструментов. При этом системы управления тестами часто не было вовсе или была, но примитивная.
-
В операционных процессах было много рутины и, как результат, рисков, связанных с человеческим фактором.
На текущий момент ситуация значительно изменилась в лучшую сторону.
-
Автотесты все чаще пишутся на нативных решениях, лежат в том же репозитории, где и код самого приложения. Зачастую автотесты пишут в том числе или только разработчики.
-
Компании стали работать с компонентными автотестами на микросервисы.
-
Автотесты стали активной частью CI/CD экосистемы, то есть от результатов прохождения тестирования зависит, пройдет фича дальше по пайплайну релиза или нет.
-
С увеличением количества автотестов, стала востребованной и распространенной облачная/многопоточная параллелизация прогонов.
-
Для формирования отчетов по автотестам появилось много инструментов. Это упрощает работу с автотестами, позволяет легко ориентироваться в них, получать информативные и интерпретируемые данные по каждому прогону.
-
Инструменты для управления проектами (например, Jira) и тестированием (TMS) стали неотъемлемой частью бизнес‑процессов, основой коммуникации и ведения задач на всех этапах их жизненного цикла.
-
Рутина активно автоматизируется с помощью всевозможных сервисов, инструментов и скриптов.
Вместо выводов
Запросы пользователей ИТ‑продуктов неизменно растут — люди очевидно хотят получать больше возможностей, удобнее интерфейсы, быстрее обновления и не только. В ответ на это повышаются требования к обеспечению качества ПО в целом — меняются подходы, паттерны, инструменты.
Но крайне важно помнить, что развитие QA — это путь самурая, у которого нет конечной цели. Потому что, то, что еще не так давно было исключением из правил, сегодня уже стало стандартом отрасли. И вполне предсказуемо, что в перспективе текущие подходы и паттерны тоже будут устаревать. Поэтому развитием QA внутри компании надо заниматься непрерывно, наравне с развитием продукта.
Автор: pifagor_mc