Новые подходы и технологии в тестировании программного обеспечения

Shift-left тестирование

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

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

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

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

В мобильной разработке, на стадии дизайна можно контролировать платформенные расхождения между IOS и Android до того как некорректные данные пойдут в код. Когда разработка ведется в сжатые сроки для приложения может быть реализован дизайн только на одну из платформ и контроль за расхождениями также может лечь на плечи тестирования. Например, технологии Touch ID и Face ID имеют отношение к IOS, но не к Android, однако периодически мы сталкиваемся с сообщением «Использовать Touch ID для входа в приложение» в приложениях из Google Play.

Вся суть Shift-left в том, чтобы минимизировать количество багов, которые могут добраться до кода. Ведь ранее тестирование экономит время и деньги.

Shift-right тестирование

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

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

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

Тестировщик — менеджер

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

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

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

TestOps — непрерывное тестирование

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

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

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

Применение ИИ в тестировании

Следуя мировым трендам, а скорее, возглавляя их, IT-сфера активно разрабатывает инструменты на основе ИИ для оптимизации собственных внутренних процессов. GPT 4 с появлением выхода в интернет получил ряд надстроек, которые позволяют находить уязвимости web-приложений, писать автотесты. Расширение Codium для intellij idea дает возможность автоматизировать процесс формирования unit-тестов. Браузерное расширение Jam позволяет собирать максимальную фактуру по багам, а встроенная GPT-модель помогает с описанием и дает рекомендации по оптимизации. 

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

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

Все новое — важно

ИТ-сфера очень быстро развивается. Любому тестировщику всегда нужно следить за трендами. Опытный тестировщик даже в отпуске не может позволить себе не читать новости о происходящих в отрасли событиях — новые технологии появляются постоянно, и о них надо знать. 

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