От IntelliSense до Copilot
“Автоматическое дополнение, как и генерация кода — технологии не новые. Помню первое знакомство с IntelliSense в Visual Studio для VB.NET в 2006 году. Для непосвященных (таких как я аспирантов) выглядело волшебством. Также помню предостережения преподавателей о непредсказуемости и абсурдности генерируемого кода. Однако наблюдая за последними достижениями генеративных ИИ-моделей, сложилось впечатление, что сейчас ИИ уже точно изменил процесс программирования. Когда OpenAI выпустил Codex, эти предположения наглядно осуществились. Наш отдел работает с GitHub Copilot; интересно было, способна ли эта вещь помочь моим тестировщикам работать быстрее и удобнее. Хотел понять, как это работает, оценить лично — и в целом неплохо.
Что касается продуктивности команды
Оценка влияния Copilot на производительность требует достаточно тонкого понимания, что значит быть продуктивным QA-автоматизатором. Банальный рост количества автоматизированных тест-кейсов за единицу времени — это, как по мне, слишком упрощенный подход. Не учитывает сложность тест-кейсов и реюзабельность при генерации тестовых данных и симуляции пользовательских действий. Кажется, оценка только по скорости может подавлять инновации, приучая автоматизаторов быстро корректировать ошибки ИИ-генерации, и всё. В долгосрочной перспективе это скажется на масштабируемости.
По итогам обсуждений в команде пришли к выводу, что продуктивность для нас сейчас заключается в следующем:
- Мотивация. По моим наблюдениям, только высокомотивированные команды показывают высокие результаты, что касается производительности. Личная мотивация — это мотор, который толкает «выше-дальше-быстрее».
- Качество кода: Команда, которая гордится своим ремеслом, будет превосходить других в долгосрочной перспективе. Качество кода — это как почетный знак, или орден, который команда носит с гордостью, что побуждает создавать новые продукты, не особо озираясь на конкурентов.
- Операционная эффективность: Более точным показателем производительности является операционная эффективность всего жизненного цикла автоматизированного тестирования, а не количество сгенерированных и проверенных тестов в единицу времени.
Измеряя производительность именно в таких терминах, получим точное представление о том, как Copilot влияет на способность команды создавать хорошие надежные тесты.
Мотивация команды
Мотивация — мощная сила, всегда приятно видеть, как твоя работа влияет на достижение общих целей. Написание сложных методов настройки тестов и данных, проверка сложных структур данных и их логов никогда особо не радовали команду. О чудо, такие тривиальные утомляющие задачи легко отдаются Copilot, положившись на его довольно точные предложения по boilerplate-коду.
Это освобождает время для более важных задач — все внимание стабильности и производительности тестов. Мы применяем паттерн проектирования POM. Copilot умеет «считывать контекст» из ранее написанных нами тестов и предлагает достаточно точный, релевантный код, это ускоряет почти все процессы.
Может быть, с Copilot я автоматизирую такое же количество тестов как и без него, а зато в конце дня я доволен своей работой. Приятно наблюдать, как daily job в Jenkins без проблем прогоняет новый тест. И да, команда солидарна со мной в оценке легкости и быстроты, которую дает Copilot.
Качество кода
В ходе наших экспериментов был обнаружен любопытный факт, что качественный код всегда порождает более качественные дополнения от Copilot. Раз так, у команды появляется стимул изначально писать хороший код, соблюдать code conventions и применять дизайн-паттерны.
Приведу несколько соглашений по коду и лучших практик, которые мы теперь усиленно применяем, после того как обкатали Copilot:
- Separation of Concerns (SoC, разделение ответственности): GitHub Copilot обрабатывает не более 6000 символов за раз. Copilot может читать только активные вкладки в IDE. Учитывая эти ограничения, соблюдение SoC в случае Copilot кажется нелогичным — тем не менее, опытным путем установлено, что подсказки более точны в проектах, где SoC-принцип очень строго соблюдался.
Например, паттерн POM требует, чтобы методы в классах объектов страницы содержали только действия пользователя, а тесты — только валидации. Copilot умеет учитывать эти методы действий, предлагая их для тестов, и делает это достаточно правильно, так что ничего не «ломается».
- Соглашение об именовании: Когда мы даем понятные, описательные имена свойствам класса, следуя соглашению о единообразном именовании, Copilot понимает контекст их использования и дальше предлагает аналогичные. Это позволяет генерировать более-менее точные подсказки и в тестовом коде тоже.
- Правильное применение инкапсуляции: Мною обнаружено, что применение стандартных унаследованных методов для создания отчетов и журналов заставляет Copilot чаще предлагать их для действий пользователя и шагов валидации.
Аналогично, когда в коде применяется инкапсуляция для сложного обхода API-ответов и вообще сложных структур данных, при генерации тестовых данных, Copilot скорее будет предлагать эти или подобные методы в дальнейшем, вместо того чтоб пытаться «выдумывать» свои уникальные логики обхода API или фильтрации.
- Неплохая обработка исключений: Раньше замечал, иногда, что Copilot не мог предсказывать очевидные исключения в коде. Однако это постепенно исправилось, когда накопилось больше методов с более качественным вводом, в общем обработка исключений пришла в порядок.
Также, у нас налажен эффективный процесс рассмотрения пулл-реквестов, который защищает от крупных сбоев в процессе тестирования и срывов графика релиза. Я попросил всех участников команды оценивать качество кода при каждом pull request. Заметил тенденцию повышения качества кода после включения Copilot в некоторых проектах. Понятно, что это субъективно и не проверяемо. Но мы оцениваем тесты и инструментальным путем, например в SonarQube, у нас статический анализ кода в проектах с Copilot.
Операционная эффективность
Понятно, что количество тестов в единицу времени — не лучший показатель производительности, но вообще скорость нельзя не учитывать. Жизненный цикл автоматизированного тестирования у нас делится на такие этапы: создание тестов, их разделение, генерация тестовых данных, валидация, дебаг и стабилизация.
Copilot вполне уверенно понимает контекст кода, который сейчас пишет команда. Поэтому он способен «принимать во внимание» похожие паттерны и в других тестах/проектах. Например последовательности пользовательских действий или вызовов методов перед тем как элемент страницы будет проверен или обработан. И предлагает код на основе подобных паттернов в следующий раз когда команда пытается делать что-то подобное. Большинство повторяющихся задач предлагаются в подсказках почти автоматически и с хорошей точностью.
Есть опция на уровне организации для подсказок на основе общедоступного opensource-кода. Мы не используем ее из-за возможных юридических проблем. Но в будущем, если этот вопрос будет уточнен и коллизии сняты, мы активируем опцию и я предвижу многократное увеличение скорости написания кода.
Еще одно применение, о котором стоит упомянуть, связано с дебагом. Copilot на VSCode предоставляет множество brush-инструментов для повышения читабельности, устранения ошибок и соблюдения чистоты кода:
В бета-версиях есть экспериментальные функции, типа объяснения кода, или «перевода» на другой язык программирования, которые иногда помогают разобраться в особенно сложных кусках (обычно унаследованных от другой команды или из библиотеки). Я не самый большой сторонник машинного перевода кода, но иногда это позволяет быстро понять реализацию, написанную на языке, не знакомом команде. Я использовал этот метод, чтобы разобраться в библиотеке http-прокси, написанной полностью на Rust, и переписать ее на Python.
Подводные камни
Выше упомянуто только то что хорошо работало. Или как мне кажется может в будущем хорошо работать. При этом нужно понимать ограничения подобной технологии.
Copilot в принципе нельзя использовать как альтернативу квалифицированным программистам. Не следует давать Copilot в руки стажерам/джуниорам QA, особенно знающим пока только скриптовые языки и больше ничего. Если в отделе не налажен надежный процесс код-ревью, Copilot лучше не применять. Об опции ‘Suggestions matching public code’ уже упоминал выше. А вообще часто вижу твиты, что люди находят знакомый код в сгенерированном ИИ-инструментами.
В целом же, продукт быстро развивается, и надеемся, что за несколько итераций все эти вопросы будут решены.»
Финансовый вопрос
Продукт коммерческий, он бесплатен только для студентов, преподавателей и участников популярных opensource-проектов. Есть trial на месяц. Индивидуальная подписка 10$ в месяц или 100$ в год. Для компаний подписка одного пользователя — 20$ в месяц.
Источник. Об авторе: QA Manager в Tavant (многопрофильная компания в Калифорнии, многократно появлялась в рейтингах лучших работодателей)
