Тестирование из первых рук

🚀 Открытый бесплатный курс «Что под капотом у ИИ» 29 сентября в 21:00 мск стартует бесплатный курс «Что под капотом у ИИ» в @qa_road_channel 🧑‍🏫 Ведущие: Дима Алексеев, Senior QA-аналитик @qa_road_channel Александр Бугров, Senior QA Engineer, магистр компьютерной лингвистики LMU München, автор канала «Тестирование из первых рук» @qa_iz_pervyx_ruk 📌 Курс состоит из 6 блоков 1. История и термины AI, ML, DL, LLM, предпосылки прорыва, пионеры отрасли 2. Как работает LLM Токенизация, эмбеддинги, attention, вероятность и сэмплинг, reasoning-модели 3. LLM в использовании Промптинг, prompt injection, галлюцинации, RAG, fine-tuning 4. Что такое AI-агент Отличие от чата с LLM, типы агентов, цикл работы агента, инструменты и память 5. Практическое применение Паттерны внедрения агентов, vibe coding, здоровье кодовой базы, данные из исследований 6. Итоговый разбор Как всё пройденное работает вместе 🧑‍💻 Для всех, кто хочет разобраться, что происходит под капотом у современного ИИ 💎 Результат: понимание архитектуры LLM и агентов, а не просто "ИИ работает как-то там" 💡 Формат: живые созвоны с вопросами в прямом эфире. Запись будет. Бесплатно! 👉 Приходить будет на канале @qa_road_channel Старт 29 сентября в 21:00 мск — не пропусти! 🚀

Последний год с лишним глубоко погрузился в ИИ темы, в коллабарции с Димой Алексеевым проводим небольшой бесплатный курс по ИИ, официальный анонс ниже:

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

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

По просьбе коллеги: 🎓 Открытый бесплатный курс по автоматизации на Python Просто и доступно для всех кто с нуля. 23 декабря запускается бесплатный курс «Автоматизация на Python (основы): Selenium + Playwright» в @qa_road_channel 📌 В программе: • Автотесты фронта (Selenium + Playwright) • Автотесты API (pytest + requests) • Работа с БД • Docker для тестов • Allure-отчёты • CI/CD интеграция 🧑‍💻 Для всех кто хочет в автоматизацию 💎 Результат: твой первый проект автотестов для портфолио. 💡 Формат: короткие видео уроки + задания. Бесплатно! 👉 Приходи в @qa_road_channel Старт 23 декабря — не пропусти! 🚀

Немного про промптинг. Есть популярный совет — чтобы создать контекст, нужно написать что-то вроде: «представь, что ты Senior Developer…». Но проблема в том, что не очень понятно, какой именно Senior. На практике я видел очень разных senior-специалистов — уровень, глубина, подходы могут отличаться кардинально. И получается, что такая роль даёт слишком расплывчатый контекст. Недавно я начал экспериментировать по-другому: вместо абстрактной роли — использовать конкретных известных людей. Например: «что бы сказал Билл Гейтс по поводу этого кода?» или «как бы это прокомментировал Линус Торвальдс?». Почему это работает лучше? Потому что у известных людей уже есть сформированное и самое главное публичное представление — их ценности, подходы, манера думать более-менее известны. ИИ опирается на этот набор характеристик, и в итоге ответ получается предсказуемее, понятнее по критериям и логике. Есть ещё интересный момент. Иногда качество результата повышают, заставляя несколько ИИ спорить между собой. Что-то похожее можно сделать и внутри одного — просто задав две разные личности с разными взглядами. Например: «что бы сказал Гейтс?» — «а что бы ответил Торвальдс?». Получается мини-дискуссия прямо внутри модели. Интересно, что такие ответы часто оказываются глубже и детальнее, чем когда просто пишешь “представь, что ты Senior Developer”.

В последнее время обратилась пара коллег с просьбой помочь с названиями определенных элементов в проекте. Если возникнет такая необходимость, то первое, что нужно сделать: chrome, devtools, element, навести курсор на соответствующий элемент и изучить всю информацию по нему, название элемента обычно видно сразу

Интересная новость на тему postman: https://blog.postman.com/early-access-to-postman-api-performance-testing/ У jMeter и ко появляется конкурент. Сейчас часто используются оба инструмента параллельно: jMeter для тестов производительности, а postman для API тестов. Вполне вероятно, что через какое-то время будет достаточно только postman. Помешать этому может желание монетизировать postman.

В продолжение темы докера. Такое описание докера выдает chatGPT: Докер - это программное обеспечение для упаковки, доставки и запуска приложений в изолированной среде, называемой контейнером. Контейнер представляет собой небольшое окружение, в котором запускается приложение, включая все его зависимости (библиотеки, фреймворки, среду выполнения и т.д.). Контейнеры позволяют разработчикам создавать и тестировать приложения в однородной среде, которую можно легко перенести на другие компьютеры или облака без необходимости устанавливать и настраивать зависимости каждый раз заново. Докер также предоставляет удобный способ управления и масштабирования контейнеров на серверах, а также возможность использовать готовые образы контейнеров из публичных репозиториев, таких как Docker Hub. ############################ Некоторые сценарии использования докера тестировщиком, если докер используется на проекте, пишу, основываясь на своем опыте: - можно локально запустить приложение - необязательно запускать все приложение, для тестирования бэкэнда достаточно запустить необходимые микросервисы - можно легко запустить приложение в любой версии или использовать любые версии микросервисов - можно локально создать имидж на основе бранча разработчика для быстрого тестирования изменений - можно локально создать имидж на основе собственных изменений. В моем случае используются имиджи/контейнеры для запуска моков, например - можно использовать докер для запуска автоматических тестов, то есть иметь соответствующий имидж и его использовать. В моем случае я создал имидж для запуска jMeter и jMeter скриптов ############################ Преимущества для тестировщика: - независимость от внешней среды - возможность гибко настраивать приложение - возможность получить доступ к логам для анализа ошибок - по сути можно проводить любые виды тестирования приложения, запущенного в докере: ручное, автоматизированное. В моем случае я провожу еще и тестирование производительности - это позволяет быстро выявить критические проблемы, лично мне таким образом удалось обнаружить ряд ошибок. Но, внимание, эти тесты не должны заменять тесты с использованием стендов для тестирования производительности. ############################ Проблемы, с которыми сталкивался: - Docker Desktop на Windows работает не идеально, иногда падает - докер требуют определенных ресурсов, правда небольшое приложение можно запустить и на относительно слабой машине - локальная конфигурация может отличаться от той, что используется в продукции, например, docker-compose vs. kubernetes