Семь раз оттесть, один раз деплой
Всем привет! Меня зовут Юля Трусова и я тестировщик. А ещё я лидирую под ключ одно из самых крупных и древних комьюнити в Авито — QA Community. В этой статье я расскажу про свой подход к теме, поделюсь важными вехами в становлении комьюнити и с удовольствием почитаю про ваш опыт в комментариях.
14 ошибок TypeScript. Такой был результат моего первого промпта в ChatGPT, когда я попросил написать тесты для React-компонента.
Через несколько месяцев тот же запрос "напиши тесты" выполняет мультиагентный пайплайн из 7 AI-агентов. Он сам планирует тест-кейсы, пишет код, проверяет его по философии RTL, а потом намеренно ломает компонент, чтобы убедиться, что тесты не врут. 40+ компонентов уже прошли через него на проде.
Это история про путь между этими двумя точками. Без прикрас, с тупиками и неработающими подходами.
Даже с чистым кодом тесты могут падать с завидной нерегулярностью. Раз в десять прогонов, чаще в CI, чем локально. Не потому что CI какой-то особенный, а потому что там может быть меньше CPU, выше latency между сервисами и куча параллельных процессов. Асинхронные проблемы никуда не деваются и локально, но более мощная машина и быстрая сеть их маскируют. Стоит условиям стать чуть хуже, и тайминги разъезжаются: фронтенд уже отрисовал результат, бэкенд ещё обрабатывает запрос, а транзакция в базу ещё не закоммичена. Тест идёт проверять и не находит там того, что ожидает.
Три темы, которые дают стабильность на больших числах:
В дашборде было 83 успешных engagement’а. В аналитике X — 16 настоящих ответов. Пять к одному. Неделю я этого не замечал.
Контекст: у меня автономный AI-агент, который пишет комментарии в X (Twitter) от имени клиентов. Находит релевантные треды, генерирует ответ, публикует через браузер. Без моего участия. Ну, предполагается что без моего участия.
Матрица трассируемости (RTM) — инструмент, который помогает QA видеть реальное покрытие требований и не тестировать «вслепую».
В статье разберём:
• что такое RTM и зачем она нужна
• какие бывают типы трассируемости
• как выглядит матрица на практике
• типичные ошибки при работе с RTM
примеры таблиц, схемы и чек-лист для QA
Привет! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. Мы решили не нанимать ещё двух тестировщиков, а написать систему AI-агентов, которая берёт на себя 80% рутины QA-инженера – от анализа требований до Merge Request с готовыми автотестами. В этой статье расскажу, как устроена архитектура, какие грабли мы собрали, и что из этого вышло на практике.
«Кроилово ведёт к попадалову» — знает каждый русскоязычный, поляк бы сказал — «Tanie mięso psy jedzą», в британских колониях прозвучит — «Penny wise, pound foolish»...
Это история о том, к чему приводит экономия на SMM персонале и незнание банального
«Quis custodiet ipsos custodes?»
Postman используют миллионы разработчиков — и не зря. Удобный интерфейс, коллекции, окружения, командный доступ. О чём еще мечтать?
Но если вы большую часть дня проводите в IDE, у этого подхода есть один постоянный friction point: нужно переключаться. Открыть Postman, вспомнить, где нужный запрос, скопировать токен из консоли, вставить руками. Потом вернуться обратно. И так по кругу.
В этой статье разберем альтернативный HTTP-клиент, который встроен прямо в IDE и его возможности для тестирования API.
В статье разобраны основные группы мероприятий, из которых состоит процесс тестирования. Вы узнаете:
▪️ чем отличаются тестовые условия от тест-кейсов,
▪️ зачем нужны таблицы решений и попарное тестирование,
▪️ как мониторинг и контроль помогают в общем процессе,
▪️ почему ретроспектива тестирования так же важна, как и планирование.
Материал будет полезен тестировщикам, разработчикам, тимлидам и всем, кто хочет выстроить процесс тестирования.
Привет всем, я Надежда Дудник, главный инженер по тестированию в Сбере, ментор по тестированию ПО и автор канала по тестированию @protestinginfo.
Хочу вам рассказать о важности написания хорошо структурированных тестовых сценариев на примере стратегии их составления для бэкенда.
Всем привет! Я Лина, инженер по обеспечению качества в Команде Контента и Трафика в Банки.ру.
Я хочу рассказать, как мы работали над обновлением сложного сервиса – Народными рейтингами. В этой статье представлен каждый шаг от макетов до пострелизного теста: со своими заметками, выводами и, конечно, примерами конкретных багов, которые попадались во время работы над новыми Народными рейтингами и редизайном НРСК.
Здесь мы рассматриваем фабрики в тестировании. На очень элементарных примерах, с использованием языка python и инструментов Django, pytest, factory_boy.
JMX-файл на 50 000 строк, merge-конфликты при каждом коммите и PR-ревью, которое никто не читает - знакомо? Я столкнулся с этим на реальном проекте и нашёл способ декомпозировать JMeter-тесты так, чтобы основной файл похудел в 10 раз, а работать с тестами стало можно прямо из IDE.
Если вы уже имели опыт написания Ul-тестов для проверки страниц и форм, то, вероятно, задумывались: "Почему бы не протестировать весь сценарий целиком?" Так родилась идея делиться опытом, как мы внедрили подобный подход: начиная с первых шагов, объясняя, почему объединили UI, АРІ и SSH в единый интеграционный контур, и какие инструменты используем.
В первой части был заложен фундамент: локаторы, «умные» ассерты и хелсчеки. Это критически важные вещи, но на масштабе в 100+ тестов неизбежно возникает «второй слой» проблем — сложность диагностики и изоляция данных.
Неделю назад по сети пронеслась новость о том, что генеральный директор Y Combinator Гарри Тан с помощью ИИ Claude пишет десятки тысяч строк кода ежедневно и имеет виртуальную команду из 10+ ролей. Я решил проверить насколько это решение действительно рабочее и не является ли оно очередным хайпом. В этой статье мы разберемся, что за инструмент использует CEO Y Combinator и в чем его особенности. А также попрактикуемся в его использовании.
Так как типичная LLM обучена работать с текстом, первые попытки были просто давать модели чистый HTML. И как не странно, это даже работало, причём надёжнее, чем ожидалось скептиками.
Одновременно в параллельной вселенной существовали E2E тесты, которые имитировали живых юзеров, нажимали на кнопки и заполняли поля. И этим тестам тоже как-то надо было отслеживать изменения на экране. Сравнение скиншотов оказалось крайне не надёжным методом. Тут разработчики Playwright – это известный open source фреймворк для E2E тестов, под крылом Microsoft - вспомнили про ARIA и экранные читалки.
Пришёл в команду, открыл тесты — should render, снэпшоты, CSS-классы в ассертах. CI зелёный, покрытие растёт. Всё хорошо?
Нет. Тесты падали при любом рефакторинге, но пропускали реальные баги в логике. Ложная уверенность, которая хуже отсутствия тестов. И проблема была не в отдельных файлах — а в самом инструменте, который провоцировал так писать.
Проблема не в том, что инструментов мало. Проблема в том, что большинство из них построены вокруг браузера прошлого поколения, тогда как frontend уже давно живёт внутри runtime. Именно из этой практической боли появился собственный runtime-инспектор — сначала как консольный скрипт для одной конкретной задачи, а затем как полноценный инструмент, который неожиданно нашел отклик у QA и разработчиков.
Сегодня разберём реальный кейс пентеста крупного российского банка. Поговорим о том, как двухфакторная аутентификация превратилась в иллюзию безопасности, и что делать, чтобы ваша защита не была такой же. Речь пойдёт не о сложных zero‑day эксплоитах, а о банальной ошибке, которая до сих пор встречается. Мы посмотрим, как 4 цифры в SMS и отсутствие лимитов открыли доступ к паспортам, документам и финансовым заявкам. И главное — разберём, как закрыть эту дыру ещё на этапе проектирования.