Октябрь ворвался в нашу жизнь, разрушив планы на сентябрь 😀 Свел в кучку некоторые материалы, над которыми я усердно трудился. Я ведь пишу посты без ИИ, вот этими вот руками. Поддержите меня какой-нибудь реакцией 🙏🏻 Что там с ИИ ▪️Сейчас в мире ИИ обновления сыпятся почти ежедневно, уже внимание к ним ослабло, но за топовыми моделями следим тут и тут. ▪️Еще вот тут писал про новый класс моделей, очень быстрых в классификации. Сейчас, кстати, такие стали появляться и в опенсорсе. ▪️Чего ждать от ИИ до конца десятилетия - тут. Подходы и процессы ▪️Метод Event Storming для изучения командой бизнес-доменов ▪️Постановка задач с помощью EARS ▪️Поиск бутылочных горлышек в процессах с помощью теории ограничений В помощь разработке ▪️Структурирование контента с помощью schema.org ▪️Нагрузочное тестирование приложений Из жизни ▪️Экономим на MS Office ▪️Путешествие мухи во все тяжкие ▪️Почему кокпиты самолетов разных цветов #summary

Знаете, что такое Хабраэффект? Это ситуация, когда все решили зайти на ваш сайт одновременно. Ну и сайт, конечно, не вывез. Конкретно этот термин связан с популярной площадкой Хабр. Но вообще эффект замечен ранее и в документах значится, как Слэшдо́т-эффе́кт. Когда я участвовал в разработке платформы лояльности, у нас было старое легаси-ядро, без всяких кэшей и очередей. Вот оно и падало перед Новым годом, потому что не могло обслужить такое количество пользователей, желающих лояльности. Чтобы до такого не доводить и заранее понимать, где бутылочное горлышко по Голдратту, надо делать нагрузочное тестирование. 🔹Вот, например, Apache JMeter как раз для такого. Опенсорсный инструмент, написанный на Java, который симулирует тяжелую нагрузку на серверы и целые сети. Имитирует пользователей, отправляет HTTP-запросы, работает с API, базами данных и другими протоколами. Позволяет строить сценарии: авторизация, поиск, добавление данных и так далее. Там даже есть специальная Test IDE для создания и отладки тест планов. 🔹У Grafana тоже есть свой тестировщик нагрузки - k6. Они используют подход "тест как код", можно писать скрипты тестирования на JS/TS, хранить в репозитории и встраивать их в CI/CD. Нативно интегрируется с Grafana. 🔹Еще вариант - Locust, тоже опенсорсный. В нем тоже пишутся сценарии в виде скриптов, но уже на Python. То есть если у вас питонисты в команде, то можно не распыляться, использовать обычные библиотеки. Но есть и UI. 🔹А если у вас пишут на Scala, Java или Kotlin, то можно посмотреть на Gatling. Принципы те же, что и в предыдущих, язык другой. Высокая производительность, асинхронная архитектура. 🔹Ну и есть отечественный инструмент - Yandex.Tank, тоже опенсорсный, поддерживает разные генераторы нагрузки. Только тестируйте аккуратно, не уроните прод раньше времени 😉 #tools

Пока мы без советов тестировщиков. Не доходят руки проверить, дополнить и запланировать новую партию. Сейчас все крутится вокруг платформы и фиксов багов. Выкатил несколько новых сборок для Android и iOS вчера. 2го октября выступаю на степикон и готовлю доклад про ИИ и геймификацию. Это платная конференция для авторов курсов на Stepik и других платформах, но материалы к докладу по сути строятся на двух статьях, которые вы можете прочитать сами: ИИ в курсах по тестированию Геймификация в курсах: результаты внедрения Как и обещал, сажусь за обновление продвинутого курса в модулях: мобильное тестирование, git, bash, ci, cd. Уроки и скрины уже есть. Осталось только их проверить.

Хорошее время для QA-инженеров. Часто слышу тезисы в духе:

AI-coding убил QA

Это не так. Точнее – не совсем так. Если мы внедряем AI-инструменты в процессы разработки, то написание кода достаточно сильно ускоряется. В зависимости от дисциплины и ответственности конкретного разработчика, это ускорение может в большей или меньшей степени влиять на качество производимого кода. Уже на первых этапах внедрения AI-инструментов в процессы разработки, мы получаем "затор" на стадиях ревью и тестирования. Этот затор кому-то придётся разгребать... Желательно – тоже с использованием AI в качестве инструмента. Здесь и появляется QA-инженер. Учитывая, что качество кода – одна из основных претензий к AI-generated-коду, роль грамотного QA (и грамотного QA внутри каждого разработчика) сильно повышается. QA-инженер отвечает за выстраивание quality-gates на разных этапах SDLC, а также организовывает процессы тестирования. QA-инженер даёт гарантию, что код, попавший в продакшн, соответствует конкретным критериям качества. Проблема в том, что в небольших командах QA-инженеры встречаются достаточно редко. Там чаще:

Ну, сидит у нас тестировщик, за плошку риса интерфейсы тыкает, проверяет, что они тыкаются

Эти тестировщики на процесс AI-SDLC влияют, скорее, негативно. Так как, под большим напором задач от AI-accelerated-разработчиков, выбора у них два – либо накапливать себе объёмы для тестирования, либо снижать качество проверок. В первом случае мы получаем нивелирование ускорения time-to-market, как одного из преимуществ AI-SDLC, а во втором – снижение стабильности прода. На этой неделе был "День тестировщика" (9 сентября). Я чуть опоздал с пожеланиями, но всё же: Пользуйтесь теми возможностями, которые предоставляют изменения на рынке. Изучайте глубже процесс AI-SDLC и то, как вы можете повлиять на качество кода на выходе. Потребность в QA-инженерах, способных работать в цикле AI-SDLC, будет только расти. Вопрос для дискуссии: Готовы ли QA-инженеры заменить в формате Tiny-teams разработчиков, не бравших на себя ранее ответственность за то, что их задача доедет до прода?

Нелепости агентов Агентная разработка - веселая штука конечно. Вот планируешь и кодишь несколько дней с Астрой, Фейблом и Опусом, а потом на e2e вот такое вот выясняется (см. скрин и пояснения в конце). И это прям системная история - 99% получается хорошо и правдоподобно, а в каком-то неожиданном месте Но справедливости ради - это был сложный и огромный кусок работы на десятки тысяч строк кода, хоть и делался в лучших традициях SDD с хорошим планом. Выводы? 1. Делайте e2e тесты - причем как классические через условный Playwright / XCUIAutomation и тд, так и агентные "JIT" тесты - когда агент сам запускает вашу систему в около продовых условиях и ведет себя как Manual QA. 2. Рефлексируйте - если все-таки что-то вылезло несмотря на все ваши пятьсон уровней гардрейлов, обязательно ищите источник проблемы - то есть, в какой момент вашей даркфактори агентного пайплайна вылеза ошибка и как она вообще дошла до live e2e. * Контекст: я разрабатываю агентный интерфейс к одному из своих проектов (в данном случае - это MCP + skill) и вот там оказалось, что ответ в во всех MCP инструментах просто дублируется (структурированный + обычный текст) - абсолютно комичный дефект, который добрался аж до финальной стадии верификации. Live e2e же там устроен так, что сильный агент тестирует другого агента на предмет того, как тот справляется с задачами из юз кейсов - и то, как быстро он справляется, и сколько токенов у него на задачу уходит. Это, кстати, правильный подход и к evals скиллов тоже. Если тоже сталкивались с подобными нелепостями агентов - расскажите в комментариях что это было и как боролись. @ai_driven