Новые подходы и технологии в тестировании продуктов
Изображение: Maridav/shutterstock.com
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 можно назвать сведение всех данных в единую систему. Все метрики и результаты тестирований объединяются в общий отчет, который можно представить заказчику в виде графиков. Также это позволяет контролировать, какие кейсы пройдены вручную, а какие — автотестами, что помогает избежать лишней работы ручных тестировщиков и, как следствие, экономить время и ресурсы.
Применение ИИ в тестировании
Следуя мировым трендам, а скорее возглавляя их, ИT-сфера активно разрабатывает инструменты на основе ИИ для оптимизации собственных внутренних процессов. GPT 4 с появлением выхода в Интернет получил ряд надстроек, которые позволяют находить уязвимости веб-приложений, писать автотесты. Расширение Codium для intellij idea предоставляет возможность автоматизировать процесс формирования unit-тестов. Браузерное расширение Jam помогает собирать максимальную фактуру по багам, а встроенная GPT-модель — с описанием, а также дает рекомендации по оптимизации.
И хотя на сегодня даже самые продвинутые инструменты на основе ИИ не могут полноценно заменить человека, уже есть тенденция на повышение спроса на специалистов, которые в своей работе умеют применять ИИ. В рамках тестирования это оптимизация и автоматизация рутинных процессов, таких как написание тест-кейсов.
В заказной разработке мы часто сталкиваемся с требованиями вести документацию в инфраструктуре заказчика и соответствовать внутренним регламентам. Для специалиста это не проблема, а вот для ИИ необходимо будет передать определенный пул данных, чтобы нейросеть смогла скопировать стиль и правила формирования тестовой модели. В случае с открытыми моделями с машинным обучением это неприемлемо из-за угрозы утечки данных. Иными словами, мы еще сталкиваемся с проблемами, но вектор на развитие ИИ в тестировании очевиден.
Все новое — важно
ИТ-сфера очень быстро развивается. Любому тестировщику всегда нужно следить за трендами. Опытный специалист даже в отпуске не может позволить себе не читать новости о происходящих в отрасли событиях — новые технологии появляются постоянно, и о них надо знать.
Любые инновации заслуживают внимания. Порой даже незначительная идея может спровоцировать цепную реакцию, которая позволит выработать кардинально новые подходы к работе и выведет обеспечение качества на новый уровень.
Опубликовано 30.07.2024
