Webhook часто воспринимают как простой механизм доставки уведомлений: пришло событие — обработали — вернули 200. На практике именно в этом месте возникают проблемы с двойными начислениями, потерянными событиями и некорректными состояниями данных.
В статье разбираем, какие вопросы должен учитывать системный аналитик при описании требований к webhook‑интеграциям и почему надёжность начинается ещё на этапе проектирования.
Первое нагрузочное тестирование часто начинается с формулировки «давайте запустим побольше пользователей и посмотрим».
В статье разбираем, почему этого недостаточно и как собрать осмысленный план: определить цель, смоделировать реальную нагрузку, выбрать метрики и понять, где система начинает деградировать.
Когда две команды третий день спорят о релизе, а в чат уже добавили нескольких руководителей, проблема часто кроется не в аргументах.
В статье разберём, в какой момент вопрос действительно пора эскалировать, что передавать наверх и как получить решение, не превращая процесс в поиск виноватых.
Редкий сбой в распределённой системе может месяцами ускользать от команды, а при попытке воспроизведения исчезать из‑за изменившегося порядка событий.
В статье разберём, как deterministic simulation testing помогает управлять временем, сетью и отказами, воспроизводить сложные сценарии по seed и проверять системные инварианты на примерах FoundationDB и TigerBeetle.
Одноразовая ссылка сработала только один раз, старый пароль больше не подходил, а все проверки прошли. И всё же пользователь снова потерял доступ к аккаунту.
Разбираемся, какой сценарий пропустил тестировщик и почему проверять отдельный токен недостаточно.
Когда до релиза остаётся день, а полная регрессия занимает три, тестировать «самое важное» уже недостаточно. Нужно быстро понять, какие проверки первыми дадут сигнал о критичных дефектах: что связано с изменениями, деньгами, данными, интеграциями, частыми пользовательскими сценариями и зонами, которые уже ломались раньше.
В статье разбираем, как выстроить порядок регрессионных проверок, чтобы не делать вид, будто сокращённая регрессия равна полной, а честно управлять рисками перед выпуском.
Начинаете писать E2E-тесты? Думаете, нужно просто открыть страницу, нажать кнопку и написать expect?
Разберем на примере Playwright, почему отчёт может быть зелёным, но бесполезным.
Flaky‑тесты сложно ловить даже привычными инженерными методами: они ломают CI, подрывают доверие к автотестам и часто воспроизводятся только тогда, когда уже никто не понимает почему. Кажется логичным поручить такую задачу LLM: показать модели код теста и попросить определить, насколько он подозрительный.
В статье разбираем исследование, где этот подход проверили на практике, и смотрим, почему хорошие метрики на датасете ещё не означают, что модель действительно понимает природу flaky‑поведения.
Пятница, до релиза осталось два часа, а на финальной проверке всплывают баги: зависание после оплаты, профиль без обязательного телефона, расхождение в отчёте на несколько рублей. Для QA в такой момент важна не паника и не формальное «блокер/не блокер», а быстрая оценка последствий: кто пострадает, что сломается, есть ли обходной путь, видит ли команда проблему в логах и можно ли безопасно откатиться.
В статье разбираем три типичных предрелизных дефекта и показываем, как принимать решение о выпуске без гадания на severity.
Когда требования расплываются, команда быстро теряет не только время, но и ощущение смысла: задачи переделываются, приоритеты скачут, заказчик недоступен, а разработчики всё чаще работают «наугад».
В статье разбираем, почему проблемы с требованиями редко ограничиваются плохим описанием задачи, как на них влияют коммуникация, мотивация и вовлеченность участников проекта, и почему даже хороший шаблон не спасает, если команда и заказчик не умеют договариваться.
Я всё чаще замечаю, что разговоры о качестве программного обеспечения как будто застряли в прошлой эпохе. Мы по привычке обсуждаем тест-кейсы, регрессию, покрытие, приёмку перед релизом и автоматизацию проверок, как будто этого по-прежнему достаточно, чтобы уверенно говорить о качестве продукта. Но сама среда, в которой живёт современное ПО, уже давно стала другой.
Когда LLM перестаёт быть просто чат-интерфейсом и начинает сама планировать шаги, вызывать инструменты и общаться с другими агентами, ломаются и привычные способы контроля. В статье — о том, почему для агентных систем уже недостаточно мерить качество ответа, какие новые метрики нужны для оценки их работы и как меняются требования к безопасности, трассировке и эксплуатации таких архитектур.
В командной работе есть парадокс, который раздражает сильнее, чем чужие ошибки. Ты объясняешь, и объясняешь все верно, но твой собеседник тебя не понимает, хоть ты тресни. Не его, разумеется. По столу например :)
Эта ситуация, в общем-то, не редкая и встречается почти повсеместно. Я собрала небольшой гайд по ясной коммуникации в работе про то, как этого избежать.
Нет большой разницы в инструментах, когда речь идет о создании простеньких чат-ботов. Но когда вы работаете над продуктом посерьезнее, например создаете сложного AI-агента или работаете с чувствительными данными, облачные LLM начинают выставлять большие счета. И не только финансовые.
Что если переход на локальную инфраструктуру (вроде Ollama) это решение, которое не просто поможет сэкономить, но изменит саму динамику разработки?
Если вы попробуете загуглить, кто такой продакт-менеджер, вы получите красивую, но неоднозначную картинку. Стратег, лидер, аналитик, мини-сео. А еще, если открыть 10 вакансий от 10 разных компаний, то вы увидите 10 разных ролей.
Так кто же это такой? Давайте разберемся в этом вопросе подробнее.
Уже несколько лет подряд у всех на слуху ИИ и тезисы о том, что он заменит человечество, а если и не заменит, то ускорит до немыслимых высот. Сегодня я хотела бы подискутировать на эту тему в области обеспечения качества, хотя рискую оказаться в ряду динозавров.
Всем привет, меня зовут Настя, и мне НЕ нравится, когда наши компании требуют от нас повсеместное внедрение искусственного интеллекта во все процессы.
Prompt-инъекции часто воспринимают как частную уязвимость или проблему безопасности. На самом деле это лишь один из наиболее наглядных примеров архитектурных ограничений LLM.
Эти же механизмы лежат в основе галлюцинаций, ложной уверенности и ошибок LLM в обычных бизнес-процессах. Даже без атак и при «хороших» промптах.
По мере того как приложения на базе генеративного ИИ всё глубже встраиваются в нашу жизнь, нам необходимо искать способы противодействия этой уязвимости. В этой статье рассмотрим подходы, позволяющие снизить риски.
В разработке сложного программного обеспечения и систем одной из постоянных проблем является формулировка требований, ориентированных на пользователя, которые одновременно должны быть технически реализуемыми.
В этой статье представлена новая методология, сочетающая пользовательские истории с JTBD в контексте сложных проектов.
Большие языковые модели, типа GPT, Claude, Gemini и другие ИИ-системы, поразили разработчиков своей способностью генерировать тексты, звучащие как человеческие. Однако, если вы когда-либо использовали ChatGPT или подобные инструменты, вероятно, они не раз уверенно говорили вам что-то совершенно неверное. Эти ошибки ИИ, часто называемые «галлюцинациями», варьируются от незначительных фактических ошибок до полных выдумок. Они могут быть забавными (например, ИИ изобретает вымышленный исторический факт) или представлять серьезную проблему (представьте, что ИИ-ассистент предлагает несуществующую функцию или чат-бот выдает медицинский совет, которого не существует).
В этой статье мы рассмотрим, почему языковые модели галлюцинируют и, что более важно, как мы можем уменьшить эти галлюцинации. Мы будем использовать интуитивно понятные примеры и аналогии, чтобы все было доступно, а также предложим инструментарий бесплатных техник, которые помогут удержать результаты работы ИИ в рамках реальности.
11 суровых истин, скрывающихся за KPI поддержки клиентов с помощью чат-ботов. Выводы, основанные на жестких данных, опыте неудач и тех немногих, кто действительно понимает, как все работает.
Если вы отвечаете за эффективность ИИ-поддержки, приготовьтесь. Настало время разоблачить скрытые ловушки, подводные камни и радикальные подходы, которые переопределяют, что на самом деле означает автоматизация удовлетворенности клиентов.
