Баг в проде — кто виноват?
На QA-days: Оkko, ИнфоТеКС и Piter QA эксперт из Okko показал, как в компании ZBP учитывают не только критичность бага, но и причины его пропуска. Результат: багов первой категории стало в 2,5 раза меньше. Просто показали разработчикам, сколько они выкатывают.
Ещё больше о мероприятиях — в нашем TG-канале.
QA без рутины: нагрузка, автоматизация, AI и новые инструменты
В тестировании регулярно появляется новая задача, к которой вчера ещё можно было не прикасаться: проверить сервис под нагрузкой, автоматизировать UI и API, разобраться с трафиком или подключить ИИ к автотестам.
И каждый раз приходится выбирать: долго собирать решение по документации и чужим кейсам или посмотреть, как такую задачу решают на практике.
Собрали бесплатные уроки недели, которые помогут на практике разобраться с наиболее часто встречающимися проблемами.
Нагрузочное тестирование
13 августа, 20:00. «Минимум для старта: как провести свое первое нагрузочное тестирование». Записаться
Автоматизация тестирования
20 августа, 20:00. «Как ускорить создание автотестов с помощью локальных ИИ‑моделей». Записаться
3 сентября, 20:00. «UI и API тестирование с Java и Playwright». Записаться
22 сентября, 20:00. «Playwright JS: как быстро начать писать автотесты?». Записаться
22 сентября, 20:00. «Автоматизация управления трафиком с mitmproxy». Записаться
ИИ в работе тестировщика
2 сентября, 20:00. «ИИ для тестировщика: инструменты, которые уже меняют профессию». Записаться
8 сентября, 19:00. «Автотесты 1С через ИИ: от запуска до контроля результата». Записаться
Game QA
24 августа, 20:00. «Тестирование игровых уровней: как находить ошибки, которые влияют на игровой опыт». Записаться
Выбирайте направление под свою текущую рабочую задачу и приходите разбирать её на практике. Участие в открытых уроках бесплатное, нужто только зарегистрироваться.
А если хочется посмотреть на QA шире — читайте материалы:
«Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)» — о том, почему качество всё сложнее подтверждать только набором проверок перед релизом и как меняется роль QA в постоянно меняющихся системах.
«6 ошибок в метриках дефектов, из‑за которых QA теряет контроль над качеством» — о ситуациях, когда дашборды выглядят хорошо, количество багов снижается, а реальное качество продукта при этом может ухудшаться.
Полный список бесплатных уроков августа смотрите в дайджесте.
Подборка материалов: что почитать тестировщику
Собрали в одном месте материалы о разных сторонах работы тестировщика: от проверки требований и верстки до инструментов и коммуникации внутри команды. Будет полезно и тем, кто только начинает работать в тестировании, и тем, кто уже в профессии и хочет узнать, как к знакомым задачам подходят коллеги.
Какие ожидания от профессии расходятся с реальностью и чем на самом деле занимается тестировщик.
На что обращать внимание при проверке интерфейса кроме соответствия макету: тексты разной длины, переносы, отступы, состояния элементов и работа с DevTools.
➡️ Как начинающему тестировщику выстраивать рабочий диалог в команде
Как задавать вопросы, обсуждать баги без конфликтов, уточнять требования и находить общий язык с разработчиками и аналитиками.
➡️ Инструменты ручного тестирования
Подборка сервисов и инструментов, которые помогают быстрее готовить проверки, работать с тестовыми данными, файлами, запросами и интерфейсами.
Как находить проблемы еще до разработки: проверять требования на полноту, однозначность, выполнимость и использовать для этого вопросы, чек-листы, прототипы и другие техники.
Сохраняйте подборку, чтобы материалы всегда были под рукой ❤️
Привет! На связи снова QA-сообщество 2ГИС. Подготовили новый дайджест свежих релизов.
Появилась новая модель тестирования компонентов — stories и galleries. Теперь можно быстро создавать сценарии с конкретными параметрами и моками, а затем запускать их из галереи. Добавили возможность прерывать долгие операции через AbortSignal. Скриншоты теперь поддерживают формат WebP с разным качеством. Улучшены фильтры тестов и добавлен режим изолированных повторов для минимизации мешающих друг другу тестов. Обновились API браузера и сетевых операций. Debian 11 больше не поддерживается.
➡️ uv 0.12.0
Усилена безопасность и совместимость: теперь запрещены устаревшие форматы архивов и опасные wheel-файлы, способные нарушить виртуальное окружение. Возвращена упаковка проектов по умолчанию с uv_build. Улучшена проверка хэшей зависимостей и работа с сертификатами. Добавлено много новых стабилизированных функций и исправлений.
Поддержка документации в Markdown и Google Style форматах облегчает создание описаний ключевых слов. Консольное логирование расширилось — теперь можно использовать собственные логгеры. Появилась возможность запускать тесты прямо из Markdown-файлов. Несколько мелких правок и исправлений.
Финальный бета-релиз с важными исправлениями и новинками: ленивые импорты для ускорения старта, новые встроенные типы frozendict и sentinel, усовершенствованный JIT и UTF-8 по умолчанию. Многие мелкие улучшения и большая стабильность.
Исправлены ошибки с фоновыми задачами и заголовками. Появилась удобная функция app.frontend(check_dir="auto") для быстрой локальной разработки с fastapi dev. Улучшена поддержка SSE и JSONL стриминга.
➡️ Ruff 0.16.0
Значительно расширился набор правил линтинга — теперь по умолчанию включено 413 проверок вместо 59. Добавлена поддержка автоформатирования Python кода внутри Markdown. Добавлены новые форматы комментариев для подавления предупреждений и улучшен вывод исправлений.
Что из этих релизов уже интересно вам? Где планируете попробовать что-то новое? Напишите в комментариях. И заглядывайте в наш канал, чтобы быть в курсе других активностей и мероприятий для тестировщиков.
Лишнее поле в ответе, которое никто не замечает
Когда сверяешь ответ с документацией, обычно идёшь по списку из доки. Поле на месте, тип подходящий, значение похоже на правду, дальше. Так ловится отсутствие того, что должно быть, но совершенно не ловится появление того, чего быть не должно.
По документации ответ выглядит так:
{
"traceId": "7c2a8410-56f2-4f59-b921-202607230001",
"orderId": "ORD-2026-0723-001",
"status": "CREATED",
"customerId": "C-1042",
"pricing": {
"subtotal": 51960,
"discount": 5196,
"total": 46764,
"currency": "RUB",
"vatAmount": 0
}
}
А это то, что реально пришло со стенда:
{
"traceId": "7c2a8410-56f2-4f59-b921-202607230002",
"orderId": "ORD-2025-0723-001",
"stats": "CREATE",
"customerId": "C-1042",
"pricing": {
"subtotal": 51960,
"discount": 5196,
"total": 46764,
"curency": "RU",
"price": 46764
}
}Засеките тридцать секунд и посчитайте расхождения. Девять полей, глазами — ровно так, как это делается в реальной задаче.
⁂
⁂
⁂
Восемь!
traceId заканчивается на 0002, а ждали 0001 — ответ пришёл не на наш запрос.
В orderId стоит 2025 вместо 2026.
Поля status нет: вместо него stats,
значение CREATE вместо CREATED.
Поля currency нет: вместо него curency,
значение RU вместо RUB.
Поле vatAmount пропало совсем.
Появилось поле price, которого в документации нет.
Все три суммы совпали, и глаз расслабляется именно там, где надо смотреть внимательнее.
В блоке pricing по документации пять полей, а в ответе приехало шестое: price. Сверка по списку из документации его не показывает — по определению: ты идёшь по перечню известных полей, а незнакомого в перечне нет. Плюс значение в нём совпадало с total, так что даже случайный взгляд ни за что бы не зацепился. Разошлись они позже, когда логику расчёта поправили, и к тому моменту это поле уже читал клиент.
Штука в том, что лишнее поле редко бывает безобидным. Обычно это либо внутренний флаг, который случайно вылез наружу, либо отладочное значение, либо данные, которых в публичном ответе быть не должно вообще. И глазами такое ловится ровно один раз, на самом первом ответе, пока смотришь внимательно.
Я закрыл это одной проверкой. Перечислил, какие ключи разрешены на каждом уровне вложенности, и потребовал, чтобы других не было. Дальше она работает сама и краснеет, когда в ответе появляется что-то новое. В том числе когда поле честно добавили в документацию, а мне сказать забыли — тоже полезно узнать.
Собирал я это без кода, в своём настольном приложении под Windows. Указываешь путь к параметру, оператор, ожидаемое значение из документации, при желании тип данных — и всё. Запускается руками, из CI не работает, так что если у вас уже есть автотесты и человек, который их пишет, вам это неинтересно, у вас задача решена лучше.
Мне сейчас не хватает взгляда со стороны, особенно ручных тестировщиков и аналитиков. Если вы тоже проверяете API руками и автотестов у вас нет, расскажите в комментариях, как вы ловите такие расхождения. А если захочется посмотреть на инструмент вживую, напишите мне, я покажу и дам доступ, он бесплатный.
Всем привет! Рад что заинтересовало, в прошлом посту https://habr.com/ru/posts/1067648/ рассмотрели отчет базовой проверки с расчетами бизнес логики.
Составить такую проверку можно всего-то в пару кликов, если не умеете кодить не беда!
Справится даже ручной тестировщик или аналитик, достаточно ввести путь к параметру, выбрать оператор, ввести ожидаемое значение из доки, выбрать проверку на тип данных и если нужно для использования значения для дальнейших проверок то просто сохраняем в переменную.
Json и возможность проверять то я показал на картинке это лишь малая часть возможных проверок в приложении, как и в sql можно создавать множество комбинаций, работа с элементами массивов, проверки на лишние параметры, xml и многое другое.
Сейчас проходит ЗБТ Checkcraft где можете проверить с помощью встроенного Mock сервера и ли доступных API интересующий вас сценарий! https://checkcraft.ru
Всем привет! Хочу представить вам приложение, которое сможет освободить ресурс тестирования - Checkcraft.
На данном этапе ЗБТ, приложение уже показывает невероятные результаты, экономя человекочасы для аналитиков, разработчиков или тестировщиков, что соответственно разгружает команду и дает расслабить глаза.
! Сейчас покажу результат, который изменит процесс в вашей команде:
Типичная ситуация с проверкой расчетов но это же можно сделать в Postman с помощью JS или же просто в коде написать автотест. (Не нужно)
В данном приложении гораздо быстрее будет создать правила самому, в удобно интерфейсе с использованием проверок типов данных, ожидаемого значения, переменных и конечно же покрывать бизнес логику параметров с помощью сложений, вычитаний и иных необходимых сценариев чтобы ничего важного не пропустить!
Присоединиться к ЗБТ можно по инструкциям на официально сайте приложения - https://checkcraft.ru
В следующих постах покажу ВСЕ! функции приложения, это только начало...
Как делать ИПР для сотрудника: 8 правил от эксперта Okko
На QA-days: Оkko, ИнфоТеКС и Piter QA спикер из Okko поделился подходом к формированию траектории развития QA-специалиста через индивидуальные планы развития (ИПР). Доклад поможет выстроить систему, где сотрудники растут с интересом, а не «под кнутом».
Забирай 8 готовых правил в работу.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Безопасность для «чайников»: зачем обычному тестировщику знать про уязвимости
На QA-days: Оkko, ИнфоТеКС и Piter QA эксперт из Гринатом поделился простыми, но важными вещами: «На волне вайб-кодинга безопасность стала проявлять себя всё ярче. Тестирование безопасности постепенно внедряется в процессы обычных тестеров».
Узнай, как QA может влиять на безопасность продукта.
В нашем TG-канале рассказываем о технических мероприятиях и обсуждаем подборки на технические и ИБ темы.
Энтузиаст электроники и ПК под ником Uwoslab собрал внешнюю «батарею» из 192 обычных пальчиковых батареек AA (высокотоковые щелочные Pookell) и заставил на ней работать ПК без подключения к сети, без штатного блока питания.
В начале проекта Uwoslab запланировал использовать 400 батареек: закупил четыре упаковки по сотне и 50 групп по восемь элементов. В процессе работы конструкция вышла проще. На всё ушло 192 батарейки. Энтузиаст распределил элементы по трём блокам, по 64 штуки в каждом. Ток от этой такой мегабатареи идёт напрямую в материнскую плату через переходник 12V DC-to-ATX.
По прикидкам Uwoslab, именно сборка из 400 таких батареек могла бы выдавать около 160 Вт на протяжении десяти часов. Характеристики ПК: система на сокете AM4 со встроенной графикой и без накопителя. ОС грузится прямо с флешки - Hannah Montana Linux на базе Debian.
На старте батарейный блок выдавал около 13 В, а под нагрузкой встроенного теста stress-ng, когда процессор загрузили на 98%, напряжение просело лишь до стабильных 11,95 вольта — ПК работал штатно. По остаточному заряду автор предположил, что она могла бы протянуть ещё пару часов, прежде чем напряжение упадёт слишком сильно. Также энтузиаст запустил на таком ПК FreeDoom.
Тёмные века в теории тестирования
Всем привет, хочу поделиться некоторым наблюдением над инфополем в тестировании. На мой взгляд, после имперского расцвета мы лет 10-15 как вступили в тёмные века. В начале 2000-х Рекс Блэк и компания знатно потрудились над пропагандой единого глоссария, он стал общеупотребимым и более-менее исчерпывающим.
Если раньше раздробленность в терминологии и классификациях можно было встретить только в тестировании производительности, каждый крупный вендор (Microsoft, IBM, Google) придумывал свою иерархию, то теперь каждая заметная статья и/или перевод оной стремится ввести свой "уникальный" термин. Если в "имперские времена" можно было только у Microsoft прочитать про Capacity testing, за этим просматривалась некоторая логика - вендоры предлагали с терминологией свои фреймворки и подходы - то сейчас все чаще ловлю себя на мысли, что затруднительно сделать вывод о том, зачем совершенно не новаторские процессы описывают новыми терминами. Тем временем многие до сих пор путают integrated и integration...
Может мне кто-нибудь объяснить в чем "shift left" отличается от забронзовевшего раннего тестирования (early testing)? Чем модный концепт "quality gates" не просто набор "exit criteria"? T-shaped модель вполне укладывается один из 7 базовых принципов концепции тестирования - тестирование зависит от контекста, знание контекста (в том числе предметной области) необходимо для составления грамотных тестов.
Примеры можно множить и множить. А как вам кажется, имеет ли смысл кипа новых или относительно новых терминов?
Невидимый балласт: тесты, которые уже мертвы
«Иллюзия безопасности» — когнитивное искажение, заставляющее нас цепляться за мёртвые тесты. Мы боимся удалять, потому что кажется: они ещё пригодятся. На самом деле они только засоряют прогоны и снижают доверие к оставшимся проверкам.
Эксперт из Nexign на QA-days разобрал, как избавиться от балласта: чеклист, метрики и честный разбор ошибок.
В нашем TG-канале рассказываем о технических мероприятиях и обсуждаем подборки на технические и ИБ темы.
Cтaтья «BotSharp изнyтpи: ищeм cлaбыe мecтa в кoдe ИИ‑плaтфopмы нa.NET»
Пpинятo cчитaть, чтo в AI и ML бeз Python никyдa, a.NET — этo иcключитeльнo иcтopия пpo enterprise, вeб‑paзpaбoткy и гeймдeв. Ho пpoeкт BotSharp гoтoв пocпopить c этим cтepeoтипoм, пpeдлaгaя ИИ‑плaтфopмy нa экocиcтeмe Microsoft.
Mы peшили зaглянyть пoд кaпoт BotSharp и пpoвepить, какие ошибки есть в его иcxoдном кoде.
Как собрать тестовый стенд, если опыта нет, а железо разное?
IP-камеры, роутеры, одноплатники — и всё это нужно подружить в одном стенде. Эксперт ИнфоТеКС на QA-days рассказал, через что ему пришлось пройти, пересобирая стенд с нуля. Трудности, подводные камни и отсутствие опыта на входе.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Все что нужно знать QA-специалистам: сводка новостей за весну и лето 2026
Наш QA-комитет держит руку на пульсе — читает отчеты, изучает кейсы и копается в обсуждениях, чтобы вы могли заниматься более важными вещами. Забирайте выжимку всего, что стоит внимания.
📊 Рынок
Вышло крупное исследование Tricentis 2026 Quality Transformation Report: опросили 2 501 ИТ- и QA-руководителей из шести стран. 93% руководителей C-level уверены в своей стратегии тестирования, в то время как 30% руководителей QA и DevOps такой уверенности не испытывают. Доверие к ИИ-агентам упало с 48% до 34% за год.
Короче: скорость выхода ПО растет, но уверенность в его качестве падает из-за перегруженности инструментарием и невозможности перепроверить все за ИИ. Сейчас самое узкое место — валидация автотестов и подсчет реального покрытия, около 60% компаний выпускают непротестированный код в прод и теряют миллионы долларов.
Во многих источниках отмечают следующие тренды: shift-left подход к разработке ПО, плотная работа QA c data-специалистами и фокус на стратегии качества, а не на наращивании числа автотестов.
🔧 Интересные материалы на Хабре
В блоге Росгосстраха вышел целый цикл статей про применение LLM в тестировании. Начать лучше с этой статьи — про подготовку контекста для LLM: как структурировать требования, парсить PDF из Confluence, работать с макетами и диаграммами.
ВкусВилл рассказали, как превратили Swagger из документации в двигатель API-автотестов: OpenAPI Generator генерирует Java-клиенты и модели, swagger-coverage считает реальное покрытие по контракту, а LLM-скиллы по JSON-отчету сами предлагают, какие тесты дописать.
В Telegram-сообществах в последнее время гремит Playwright как наиболее перспективный фреймворк для автоматизации. Вот тут один автор решил проверить, не маркетинг ли это: собрал все свежие бенчмарки Playwright vs Selenium vs Cypress vs WebdriverIO, сравнил методологию и выяснил, что большинство цифр просто несопоставимы. Вывод: единственный процент, которому можно доверять — тот, что вы сами намерили на своем проекте.
🤖Про агентов
СВОЙ Тех описали свою архитектуру ИИ-агентов в автоматизации. Там сложный 12-актовый воркфлоу, но и результат интересный: агент анализирует собственные ошибки и обновляет конфигурацию. Можно взять как шаблон для построения агентного фреймворка.
Вот тут автор описывает, как собрал систему из 11 узкоспециализированных ИИ-скиллов, которая по Jira-ссылке сама генерирует тест-кейсы, пишет автотесты, загружает их в Zephyr и создает merge request. Можно адаптировать под свой стек.
Если вы еще не писали свой первый QA-скилл, рекомендуем почитать большой разбор от Битрикса, чем скилл отличается от RAG, Tools и MCP. Дает полное понимание архитектуры и поможет избежать ошибок новичка при написании кастомных скиллов.
💼 Для карьеры
ISTQB выпустила обновленную версию сертификации Certified Tester AI Testing (CT‑AI) v2.0, что де-факто означает появление общепризнанного стандарта использования ИИ в тестировании и тестирования самих ИИ-систем. Кому актуально, можно получить сертификат и использовать его как аргумент в переговорах с HR.
Еще нашли бесплатный 100-страничный учебник по тестированию — удобно учиться самим и использовать для онбординга.
Вот список крупных европейских и отечественных мероприятий по разработке и тестированию.
Ну и открытая вакансия Fullstack QA у нас в Cloud.ru.
👉Подписывайтесь, будем вместе повышать качество своего ПО и разбираться, чем полезны ИИ и агентные системы.
Тестирование в 2026: API, UX, QA Lead и ИИ
Тестирование давно перестало быть просто поиском багов. Сегодня QA‑инженеру важно разбираться в автоматизации, пользовательском опыте, метриках команды и понимать, как ИИ меняет профессию.
Собрали ближайшие открытые уроки для тестировщиков и QA Lead, которые помогут прокачать практические навыки и посмотреть на развитие карьеры под новым углом.
30 июня, 20:00. Тестирование UX для мобильных приложений: чек‑лист по основным проверкам. Записаться
Разберем, на что смотреть при проверке мобильного UX: сценарии, интерфейс, ошибки взаимодействия и типовые проблемы, которые влияют на пользовательский опыт.
30 июня, 20:00. Gitlab CI как конструктор workflow. Записаться
Покажем, как устроены workflow в GitLab CI и как автоматизация сборок помогает быстрее проверять изменения в проекте.
2 июля, 20:00. От API до экрана: создаём Android‑приложение на рекомендуемой архитектуре. Записаться
Полезно для QA, которые тестируют мобильные приложения и хотят лучше понимать, как связаны API, логика приложения и пользовательский интерфейс.
2 июля, 20:00. REST Assured & JSON Schema Validator: автоматизация тестирования API на практике. Записаться
Разберем практический подход к автоматизации API‑тестов на Java: проверки ответов, схем данных и стабильности интеграций.
7 июля, 19:00. Как читать баги: метрики для руководителей команд тестирования (QA Lead). Записаться
Поговорим о метриках дефектов, качестве баг‑репортов и том, как QA Lead может видеть реальные проблемы процесса, а не просто количество задач.
14 июля, 20:00. Развитие команды без найма: инструменты наставничества для QA Lead. Записаться
Разберем, как усиливать QA‑команду через наставничество, внутренний рост и передачу экспертизы без расширения штата.
16 июля, 20:00. Профессия тестировщика в эпоху ИИ — угроза потери работы или суперсила? Записаться
Обсудим, как ИИ меняет работу тестировщика, какие задачи можно усилить с помощью инструментов и какие навыки останутся критичными.
21 июля, 20:00. UI и API тестирование с Java и Playwright. Записаться
Покажем, как объединять UI‑ и API‑проверки в автотестах и использовать Java и Playwright для более устойчивого тестового покрытия.
21 июля, 20:00. Оценка трудозатрат в QA: как перестать ошибаться в сроках. Записаться
Разберем, как QA оценивать задачи точнее, учитывать риски, сложность проверок и не попадать в ловушку заниженных сроков.
23 июля, 20:00. Тестирование интернет‑магазина (eCommerce): от каталога до оплаты. Записаться
Покажем, какие сценарии критичны при проверке eCommerce: каталог, карточки товаров, корзина, оформление заказа, оплата и ошибки на пути пользователя.
Больше уроков по тестированию, разработке, искусственному интеллекту и не только смотрите в дайджесте.
Пока выбираете урок, обратите внимание на материалы по тестированию:
Хотел просто тестировать свои OTP, а выкинул почтовый сервер
Я пилю штуки, где есть регистрация и 2FA. И регулярно упираюсь в одно и то же. Чтобы проверить, что письмо с кодом доходит и парсится на фронте правильно, мне на каждый прогон нужен свежий ящик. Заводить настоящие почты муторно. Сервисы временной почты это отдельная боль: их выпиливают, лимитируют, суют рекламу, а код то приходит через три минуты, когда он уже не нужен, то не приходит вовсе. В какой-то момент надоело.
И тут дошло, что задача сформулирована неправильно. Мне не нужен ящик. Мне нужно поймать одно входящее письмо и достать из него код. А для этого почтовый сервер не нужен вообще.
Приёмник почты без приёмника почты
Cloudflare Email Routing бесплатно ловит catch-all на мой домен и отдаёт письмо прямо в Worker, в email()-handler. Не пересылкой на другой ящик, а сырым письмом в код. Ни sendmail, ни Postfix, ни IMAP-поллинга. MX поднимается за меня, я только пишу обработчик.
Дальше то, ради чего я, собственно, и сел писать. Приём держит Email Routing. Доставку готового результата мне в чат держит Telegram Bot API. И то, и другое это инфраструктура, которую я не админю. На выходе рабочий транспорт для входящей почты без единого своего сервера, без SMTP, без IMAP и без своего IP, который можно потерять под блокировкой.
письмо → MX → Email Routing (catch-all) → Worker.email() → разбор → Telegram
По команде /start выдаётся адрес, вставляешь куда надо, письмо падает в чат. Адрес живёт сутки и умирает сам.
Самое интересное это достать код
Транспорт собирается за вечер. Реальная инженерия начинается там, где из произвольного письма надо надёжно вытащить именно код. Потому что «код» в письме конкурирует с номером заказа, годом, куском телефона, суммой, id внутри ссылки. Наивное «первые шесть цифр» хватает мусор примерно в половине случаев.
Поэтому не регэксп в лоб, а скоринг. Сначала нормализую тело: срезаю шапки пересылки, невидимый мусор, превращаю Текст <url> в нормальные ссылки, иначе скорер спотыкается об id из урлов. Потом собираю кандидатов: цифровые и буквенно-цифровые последовательности правдоподобной длины, от 4 до 8 символов. И раздаю баллы.
Вверх:
близость к триггерам: код, code, verification, OTP, подтвержд…;
стоит на отдельной строке;
выделен жирным или моноширинным.
Вниз, анти-паттерны:
похоже на год (19xx/20xx);
похоже на телефон;
стоит после заказ/order;
сидит внутри ссылки;
рядом знак валюты.
Кто набрал больше, тот и код. Уезжает в первую строку сообщения, тап, скопировал. Вот эта часть и заняла итерации, остальное обвязка.
Честные границы
Чтобы не выглядело рекламой бесплатного волшебства, сразу про ограничения.
Сервис эфемерный by design. Сутки, и адреса нет. На стороне бота ничего не хранится: письмо разбирается на эдже и улетает в чат, где живёт уже у тебя. Это не замена нормальной почте, а одноразовый ящик под отлов кодов.
Inbound-only. Отправить с него нельзя. Под мою задачу, тестировать собственные флоу, этого ровно достаточно.
И про экономику честно. Лично мне бесплатного тира хватало за глаза. Но KV на free это 1000 записей в сутки, и стоило решить сделать из поделки сервис для братьев по клаве, как квота на записи кончилась. Так что перед тем как открыть доступ наружу, я доплатил за Workers. «На чужой инфре» это правда, но не «бесплатно из воздуха»: транспорт всё равно стоит пять долларов в месяц.
Итог
Завернул в опенсорс: https://github.com/investblog/mailbot. Если тоже гоняешь регистрации и 2FA и устал от рулетки временной почты, может пригодиться целиком. А нет, забирай хотя бы скоринг OTP к себе, он отвязан от Telegram и переносится легко.
Как тестировать связку продуктов, не сойдя с ума?
В этом докладе рассказали, как выстроить «танец команд»: от smoke-планов до совместной стратегии развития. Обмен экспертизой, интеграционные кейсы и живые воркшопы — всё, чтобы совместимость не хромала.
Ещё больше о мероприятиях — в нашем TG-канале.
Тестовое задание для тестировщика AI-приложений
Ранее меня просили рассказать про subj. Итак, домашнее задание по оценке навыков ML Evaluation Engineer: как оно выглядит и чего ожидают работодатели?
Сценарий тестового задания: Приложение для медицинских консультаций получает шквал жалоб от пользователей, хотя внутренняя модель анализа настроений (sentiment model) по-прежнему рапортует о высокой «глобальной точности» (Global Accuracy). Ваша миссия: найти «слепые зоны», которые скрывают метрики.
Данные: 1000 пользовательских отзывов (в формате JSON), содержащих эталонные значения (ground truth), предсказания модели и показатели уверенности (confidence scores).
Что ожидается в качестве результата?
Просто показать навыки кодинга недостаточно. В Evaluation главное – это ответ на вопрос «Ну и что?».
Структурированный аудит: Текстовое объяснение того, где именно находятся слепые зоны, подкрепленное цифрами.
Визуальные доказательства: Калибровочные кривые (Calibration Curves) и матрицы ошибок (Confusion Matrices), которые покажут, почему старые метрики пропустили провалы.
Какими навыками нужно обладать?
Чтобы блеснуть, вам понадобится «гибридный» профиль:
Теоретическая база: Понимание того, как именно модели ошибаются, и какие метрики применимы к конкретным edge cases.
Интуиция данных: Способность искать пробелы как вручную, так и автоматически.
Инженерная строгость: Навыки работы с Python для создания пайплайнов и внедрения LLM-as-a-Judge.
Стратегическая коммуникация: Умение излагать выводы структурированно, точно и грамотно.
Давайте разберем выполнение этой гипотетической задачи по фазам:
Фаза 1: «Детектив» (Анализ данных)
Прежде чем писать хоть одну строчку кода, нужно провести аудит распределения данных:
Проверка дисбаланса классов: Если «позитивных» отзывов в 10 раз больше, чем «негативных», ваша метрика Accuracy вам нагло врет.
Поиск предвзятости (bias): Не падает ли качество модели на специфических срезах (например, медицинский жаргон против разговорного языка)?
Критика статус-кво: Почему старая «глобальная точность» подвела? Сравните её с метриками, которые реально важны для несбалансированных данных.
Фаза 2: «Архитектор» (Реализация)
Теперь строим фреймворк для оценки:
Python-архитектура: Используйте чистый, модульный код. Будь то Scikit-learn или Pandas, покажите, что вы заботитесь о поддерживаемости.
LLM-as-a-Judge vs. метрики: Решите, где нужны статистические библиотеки, а где не обойтись без LLM, чтобы «рассудить» нюансы сарказма или сложного медицинского контекста.
Уверенность vs. Правильность: Напишите проверку на «уверенно неверные» (Confidently Incorrect) предсказания. Это ваши самые высокорисковые ошибки.
Фаза 3: «Стратег» (Отчетность)
Работа Eval-инженера – это на 20% получение цифр и на 80% объяснение того, что они значат.
Визуализация: Приложите калибровочные кривые и матрицы ошибок.
Бриф по «слепым зонам»: Структурируйте выводы. Где именно пробел? Модель пропускает «негатив», потому что там используются сложные термины? Объясните, почему старые метрики проглядели эти критические сбои.
Совет кандидатам
Работодатели в сфере ML Eval ищут не «Data Scientist Lite», а инженеров по качеству и надежности. В вашем GitHub должны быть не просто .py файлы, а README, который рассказывает историю рисков и их минимизации.
Это перевод моего англоязычного поста A take-home assignment for an AI QA role (другие переводы)
Как стать ручным тестировщиком?
Освоить профессию помогает не только сухая теория, но и практика. А ещё — понимание инструментов, с которыми тестировщики работают каждый день.
Если хотите изучить их на реальных задачах и под руководством практикующих специалистов, загляните на витрину курсов Хабр Карьеры, а сегодня ловите подборку этих самых нужных для каждого тестировщика инструментов:
— Postman.
Помогает отправлять запросы к API и проверять, правильно ли работает серверная часть приложения.
— Swagger.
Позволяет быстро разобраться в структуре API и посмотреть доступные методы и параметры.
— Test IT.
Нужен для хранения тест-кейсов, фиксации результатов тестирования и организации работы команды.
— Browserling.
Помогает проверить, как сайт выглядит и работает в разных браузерах.
— Charles.
Показывает сетевой трафик приложения и помогает находить ошибки в запросах и ответах сервера.