GitHub Copilot в QA

От 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 (многопрофильная компания в Калифорнии, многократно появлялась в рейтингах лучших работодателей)

Project- и Product-менеджмент в Телеграме. Только нужное

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас