Тестирование из первых рук
前往频道在 Telegram
2 098
订阅者
-124 小时
+17 天
+130 天
数据加载中...
吸引订阅者
十月 '2610月 '26
十月 '26
+647
在0个频道中
九月 '260
在6个频道中
Get PRO
八月 '260
在0个频道中
Get PRO
七月 '260
在0个频道中
Get PRO
六月 '260
在0个频道中
Get PRO
五月 '260
在0个频道中
Get PRO
四月 '260
在0个频道中
Get PRO
三月 '260
在0个频道中
Get PRO
二月 '260
在0个频道中
Get PRO
一月 '260
在0个频道中
Get PRO
十二月 '250
在0个频道中
Get PRO
十一月 '250
在0个频道中
Get PRO
十月 '250
在0个频道中
Get PRO
九月 '250
在0个频道中
Get PRO
八月 '250
在1个频道中
Get PRO
七月 '250
在0个频道中
Get PRO
六月 '250
在0个频道中
Get PRO
五月 '250
在0个频道中
Get PRO
四月 '250
在0个频道中
Get PRO
三月 '250
在0个频道中
Get PRO
二月 '250
在0个频道中
Get PRO
一月 '250
在0个频道中
Get PRO
十二月 '24
+18
在0个频道中
Get PRO
十一月 '24
+16
在0个频道中
Get PRO
十月 '24
+35
在0个频道中
Get PRO
九月 '24
+54
在1个频道中
Get PRO
八月 '24
+180
在0个频道中
Get PRO
七月 '24
+992
在0个频道中
Get PRO
六月 '240
在1个频道中
Get PRO
五月 '240
在0个频道中
Get PRO
四月 '240
在0个频道中
Get PRO
三月 '240
在0个频道中
Get PRO
二月 '240
在1个频道中
Get PRO
一月 '240
在1个频道中
Get PRO
十二月 '230
在0个频道中
Get PRO
十一月 '230
在0个频道中
Get PRO
十月 '23
+258
在0个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 14 十月 | +1 | |||
| 13 十月 | 0 | |||
| 12 十月 | +1 | |||
| 11 十月 | 0 | |||
| 10 十月 | +1 |
频道帖子
🚀 Открытый бесплатный курс «Что под капотом у ИИ»
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 мск — не пропусти! 🚀
| 2 | Последний год с лишним глубоко погрузился в ИИ темы, в коллабарции с Димой Алексеевым проводим небольшой бесплатный курс по ИИ, официальный анонс ниже: | 276 |
| 3 | В начале нового года решил начать делиться собственными подходами/правилами в выполнении задач.
Начну с документации багов. Уже публиковал кое-какие посты на эту тему, теперь постараюсь суммировать:
Основной критерий собственной оценки качества багов это отсутствие к нему вопросов. Добиваюсь этого следующими методами:
- баг, который воспроизводится в один шаг, например, верстка: скриншот с выделением бага - стрелки, рамки, лупа и тд, иногда текст в рамке с комментариями, иногда, если есть возможность, вставка скрина с правильным вариантом
- баг, который воспроизводится в два-четыре шага: скриншот, оформленный, как описано выше плюс видео как воспроизвести баг
- баг, для воспроизведения которого используется пять и более шагов: скриншот плюс видео плюс пошаговое описание. Описание сильно помогает быстро воспроизвести так сказать длинный баг, так как при наличии длинного видео его приходится пересматривать несколько раз, чтобы понять/вспомнить как воспроизводится баг. Плюс описании дает возможность указать на неочевидные детали
- баг, когда изначально неизвестно, баг это или уже фича. В зависимости от сложности использую один из названных выше способов документации плюс подробное описание почему он создан: поведение не соответствует поведению аналогичных сервисов, не соответствует стандарту и тд.
- каждый баг содержит полную информацию об окружении, версиях софта, версии браузера и тд. К сожалению, периодически встречаются баги, где эта информация не полна или вообще отсутствует.
Дисклеймер: в своей работе никогда не встречался с жесткими требованиями по оформлению багов, поэтому мог/могу себе позволить оформление согласно собственным подходам. | 1 118 |
| 4 |  没有文字... | 1 033 |
| 5 | Небольшая заметка на полях: одно время на скриншотах использовал два цвета для выделения: красный для ошибок, зеленый для всего остального.
Потом перешел на трех цветовую систему: красный для ошибок, зеленый для того, чтобы маркировать корректное поведение системы, синий для того, чтобы выделить аспекты, важные для воспроизведения поведения, например, что-то должно быть активировано, должен быть использован некий фильтр и тд.
Если первом случае очень редко, но задавались вопросы, то во втором количество вопросов свелось практически к нулю. | 1 137 |
| 6 | По просьбе коллеги:
🎓 Открытый бесплатный курс по автоматизации на Python
Просто и доступно для всех кто с нуля.
23 декабря запускается бесплатный курс «Автоматизация на Python (основы): Selenium + Playwright» в @qa_road_channel
📌 В программе:
• Автотесты фронта (Selenium + Playwright)
• Автотесты API (pytest + requests)
• Работа с БД
• Docker для тестов
• Allure-отчёты
• CI/CD интеграция
🧑💻 Для всех кто хочет в автоматизацию
💎 Результат: твой первый проект автотестов для портфолио.
💡 Формат: короткие видео уроки + задания. Бесплатно!
👉 Приходи в @qa_road_channel
Старт 23 декабря — не пропусти! 🚀 | 1 269 |
| 7 | Немного про промптинг. Есть популярный совет — чтобы создать контекст, нужно написать что-то вроде: «представь, что ты Senior Developer…».
Но проблема в том, что не очень понятно, какой именно Senior. На практике я видел очень разных senior-специалистов — уровень, глубина, подходы могут отличаться кардинально. И получается, что такая роль даёт слишком расплывчатый контекст.
Недавно я начал экспериментировать по-другому: вместо абстрактной роли — использовать конкретных известных людей. Например: «что бы сказал Билл Гейтс по поводу этого кода?» или «как бы это прокомментировал Линус Торвальдс?».
Почему это работает лучше? Потому что у известных людей уже есть сформированное и самое главное публичное представление — их ценности, подходы, манера думать более-менее известны. ИИ опирается на этот набор характеристик, и в итоге ответ получается предсказуемее, понятнее по критериям и логике.
Есть ещё интересный момент. Иногда качество результата повышают, заставляя несколько ИИ спорить между собой. Что-то похожее можно сделать и внутри одного — просто задав две разные личности с разными взглядами. Например: «что бы сказал Гейтс?» — «а что бы ответил Торвальдс?». Получается мини-дискуссия прямо внутри модели.
Интересно, что такие ответы часто оказываются глубже и детальнее, чем когда просто пишешь “представь, что ты Senior Developer”. | 1 227 |
| 8 | В последнее время обратилась пара коллег с просьбой помочь с названиями определенных элементов в проекте. Если возникнет такая необходимость, то первое, что нужно сделать: chrome, devtools, element, навести курсор на соответствующий элемент и изучить всю информацию по нему, название элемента обычно видно сразу | 0 |
| 9 | Интересная новость на тему postman: https://blog.postman.com/early-access-to-postman-api-performance-testing/
У jMeter и ко появляется конкурент.
Сейчас часто используются оба инструмента параллельно: jMeter для тестов производительности, а postman для API тестов. Вполне вероятно, что через какое-то время будет достаточно только postman. Помешать этому может желание монетизировать postman. | 0 |
| 10 | В продолжение темы докера.
Такое описание докера выдает chatGPT:
Докер - это программное обеспечение для упаковки, доставки и запуска приложений в изолированной среде, называемой контейнером.
Контейнер представляет собой небольшое окружение, в котором запускается приложение, включая все его зависимости (библиотеки, фреймворки, среду выполнения и т.д.). Контейнеры позволяют разработчикам создавать и тестировать приложения в однородной среде, которую можно легко перенести на другие компьютеры или облака без необходимости устанавливать и настраивать зависимости каждый раз заново.
Докер также предоставляет удобный способ управления и масштабирования контейнеров на серверах, а также возможность использовать готовые образы контейнеров из публичных репозиториев, таких как Docker Hub.
############################
Некоторые сценарии использования докера тестировщиком, если докер используется на проекте, пишу, основываясь на своем опыте:
- можно локально запустить приложение
- необязательно запускать все приложение, для тестирования бэкэнда достаточно запустить необходимые микросервисы
- можно легко запустить приложение в любой версии или использовать любые версии микросервисов
- можно локально создать имидж на основе бранча разработчика для быстрого тестирования изменений
- можно локально создать имидж на основе собственных изменений. В моем случае используются имиджи/контейнеры для запуска моков, например
- можно использовать докер для запуска автоматических тестов, то есть иметь соответствующий имидж и его использовать. В моем случае я создал имидж для запуска jMeter и jMeter скриптов
############################
Преимущества для тестировщика:
- независимость от внешней среды
- возможность гибко настраивать приложение
- возможность получить доступ к логам для анализа ошибок
- по сути можно проводить любые виды тестирования приложения, запущенного в докере: ручное, автоматизированное. В моем случае я провожу еще и тестирование производительности - это позволяет быстро выявить критические проблемы, лично мне таким образом удалось обнаружить ряд ошибок. Но, внимание, эти тесты не должны заменять тесты с использованием стендов для тестирования производительности.
############################
Проблемы, с которыми сталкивался:
- Docker Desktop на Windows работает не идеально, иногда падает
- докер требуют определенных ресурсов, правда небольшое приложение можно запустить и на относительно слабой машине
- локальная конфигурация может отличаться от той, что используется в продукции, например, docker-compose vs. kubernetes | 0 |
