Спрос на создание отечественных продуктов для проверки качества ПО стремительно растет. Как сообщает Ferra.ru со ссылкой на OFAC, с 12 сентября ряд IT-услуг в России будут недоступны, включая экспорт и реэкспорт IT-консалтинга, проектирования инфраструктуры, поддержки программного обеспечения для управления производством.

Для российских компаний сейчас критически важно разработать и внедрить собственные продукты, а также улучшить качество и безопасность уже существующих ПО. Какие решения для проверки безопасности предлагает отрасль сегодня, и что ждет российскую QA-индустрию в будущем, узнали у Валентина Агапитова, эксперта в сфере проверки качества и обеспечения безопасности программного обеспечения.

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

— Валентин, какие тенденции в области тестирования безопасности наблюдаете в последние годы? Что меняется?

— Тестирование безопасности сегодня — это не просто дополнительная проверка, а ключевой элемент в QA-процессах, особенно в условиях стремительно растущих кибератак и угроз информационной безопасности.

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

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

— О современных технологиях и подходах вы рассказывали на одном из главных событий индустрии в СНГ и Восточной Европе — международной конференции для ведущих QA-специалистов SQADays#33 в 2023 году. В частности, поделились инновационной методикой QA-трансформации, которая позволила вам в компании Exness увеличить штат аналитиков и разработчиков в 2 раза, сохранив при этом количество тестировщиков и скорость проверки. Какие проблемы помог решить этот подход?

— Бизнес требовал выпуск нового функционала как можно быстрее и команды сталкивались с проблемой нехватки времени на тестирование, что приводило к ухудшению качества и большому количеству багов на продакшене. Мы поняли, что проблемы в качестве возникают из-за неправильных или плохо отлаженных процессов тестирования в команде. Поэтому мы объединили лучшие QA-практики в одну общую методику, которую команды могут применить и тем самым улучшить свои процессы. Она позволяет стабилизировать процессы в команде, вставить различные проверки тестирования во все этапы разработки, а также перераспределить нагрузку с тестировщиков. Все это не снижает темпов релиза, но значительно повышает качество финального продукта.

— Говоря о скорости проверки, Вы используете подход CI/CD, который позволяет запускать тестовые прогоны на сервере компании, а не локально у тестировщика.Это увеличило количество ежедневных запусков тестов с 2 до 20 и значительно улучшило качество релизов. Какие еще преимущества для проверки безопасности дает этот метод? 

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

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

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

Стоит отметить, что это позволило повысить также эффективность команды, потому что разработчикам больше не приходится ждать результатов от команды тестировщиков. Теперь разработчики самостоятельно могут выявить и исправить наиболее крупные баги, что по итогу экономит время тестировщиков и позволяет сконцентрироваться тестировщикам на выполнении более сложных задач.

— Вы также внедрили особое тестирование, которое упрощает проверку верстки и позволяет масштабировать тестирование на разные устройства. В чем его отличие от привычных принципов проверки ПО и для каких задач его можно применять?

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

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

Когда мы внедрили автоматизированное скриншотное тестирование, процесс изменился кардинально. Теперь, после каждого обновления, система делает скриншоты интерфейса на разных устройствах и сравнивает их с эталонными изображениями. Это позволяет сразу выявить любые отклонения, будь то смещение кнопок или изменение цветовой палитры. Мы можем оперативно реагировать на эти изменения и исправлять их до того, как они попадут в финальный продукт.

Скриншотное тестирование особенно полезно при проверки совместимости с разными мобильными устройствами. Различные устройства имеют разные разрешения экранов, и проверка верстки на каждом из них вручную была бы практически невозможной. Теперь же мы можем тестировать интерфейсы на всех популярных устройствах и разрешениях, не тратя на это дополнительные ресурсы.

Кроме того, автоматизация позволила нам сократить количество ошибок в финальных версиях продуктов. Например, в одном из проектов нам удалось обнаружить проблему с отображением формы на мобильных устройствах, которая не была бы заметна при обычном ручном тестировании. Автоматические скриншоты показали смещение поля ввода, и это позволило нам исправить ошибку до того, как продукт был отправлен на продакшн.

— Для разных тестов могут быть использованы разные подходы, однако для упрощения и ускорения проверки вы разделили их на базовое и полное тестирование, что позволило сократить время проверки в некоторых ситуациях до 30 минут. Почему было выбрано именно это разделение и как подбирать подходящее?

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

Проверка с помощью Smoke-тестов занимает 30 минут, что позволяет разработчикам быстро проверить, что основные функции работают корректно, прежде чем передавать код на более детальное тестирование. Полные регрессионные тесты мы запускаем, когда система уже стабилизировалась и основные баги исправлены. Эти тесты занимают около двух часов, но они проверяют весь функционал приложения, включая редкие сценарии использования и edge cases.

Такой подход ускорил процесс разработки и позволил нам выпускать новые версии продуктов быстрее, без ущерба для качества.

— Напоследок, расскажите, в каких направлениях отечественные компании должны развиваться, чтобы пользователи получили должный уровень безопасности?

— Сегодня наиболее популярными становятся подходы Shift-Left и Shift-Right Testin. Shift-Left Testing подразумевает, что тестирование начинается на самых ранних этапах разработки, еще до того, как код написан.

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

Shift-Right Testing, с другой стороны, фокусируется на тестировании после релиза продукта, когда он уже работает в продакшене. Эти инновационные подходы позволяют выявлять проблемы на ранних этапах, анализировать и улучшать процессы и подходы к тестированию на основе предыдущих данных. А также в ближайшем будущем благодаря искусственному интеллекту станет возможно автоматизировать большинство рутинных задач.