Любой, кто хоть раз работал в тестировании, знает этот ритуал. Выкатывается новая фича, прилетает пул-реквест — и ты снова открываешь блокнот (или Confluence, или голову) и заново выписываешь: проверить валидацию, проверить граничные значения, проверить, не сломалась ли соседняя форма. Релиз за релизом одно и то же. Меняются только детали. Проблема не в том, что мы ленимся. Проблема в том, что знание о том, где обычно ломается именно этот проект, живёт где угодно — в чьей-то памяти, в старых тикетах, в комментариях к давно закрытым багам — но не в инструменте, который генерирует чек-лист. Каждый новый чек-лист рождается с чистого листа. Сервис QALens пытается закрыть ровно этот разрыв. И делает это интереснее, чем «ещё одна обёртка над GPT».
Что он делает
Базовый сценарий простой до неприличия. Ты кидаешь в QALens изменение — это может быть дифф пул-реквеста, ссылка на GitHub, скриншот UI-бага или даже голосовая заметка — а на выходе получаешь структурированный QA-чек-лист. С приоритетами, с пометками риска (High / Medium), с уровнем уверенности и с отдельным блоком «что ты можешь упустить». Последнее — самое ценное. Большинство инструментов говорят, что проверить. QALens пытается сказать, про что ты забудешь. В примере на их сайте изменение в чекауте затрагивает и авторизацию, и идемпотентность платежа одновременно — и сервис честно подсвечивает гонку между конкурентным изменением адреса и обновлением сессии, которую юнит-тесты не поймают. Это уже разговор не на уровне «нажми кнопку», а на уровне понимания, что именно сломается в проде.
Главная фишка — память
Вот здесь начинается то, ради чего стоит присмотреться. Когда тестировщик находит баг, обычный ИИ-ассистент просто фиксирует факт и забывает. QALens разворачивает одну найденную проблему в 4–5 связанных проверок — и сохраняет их как часть QA-знаний именно твоего проекта. Автор сервиса описывает это так: нашёл сегодня проблему с брендингом на экране OAuth — и будущие чек-листы начнут сами искать похожие косяки по всем флоу логина, экранам согласий, редиректам и пользовательским подписям. Инструмент накапливает паттерны багов конкретного продукта, а не выдаёт обезличенный текст по шаблону. Формула, которую любит повторять создатель, бьёт точно: ChatGPT генерирует и забывает. QALens генерирует и учится. Это и есть та граница, которая отделяет «генератор текста» от «инструмента, который со временем становится умнее на твоём проекте».
Как это устроено под капотом
Несколько решений, которые приятно видеть в продукте, работающем с чужим кодом: Код обрабатывается в реальном времени и не хранится на серверах после анализа. Запросы идут только через западных провайдеров — Anthropic, Gemini, OpenAI — на тарифах с гарантией отсутствия обучения на твоих данных. В ротации больше полусотни проверенных моделей с автоматическим фолбэком, если ответ оказался невалидным или с низкой уверенностью. Хостинг в ЕС (Кипр), GDPR по умолчанию. Для команд есть интеграции с Bitbucket и Jira — чтобы анализировать реальные пул-реквесты автоматически, а не вручную копировать диффы.
Стоит ли пробовать
Зайти можно без регистрации: три бесплатных анализа дают пощупать продукт до того, как он попросит создать аккаунт. Бесплатный тариф ограничен по объёму (3000 символов и 200 строк диффа), так что серьёзный пул-реквест туда не влезет — но для оценки «а оно вообще полезное?» этого достаточно. Кому это в первую очередь: QA-инженерам, которые устали переписывать одни и те же чек-листы, и небольшим командам без выделенного процесса регрессионного тестирования, где знание о слабых местах проекта пока живёт только в чьей-то голове. Кому пока рано: если у вас зрелый процесс с автотестами, покрывающими как раз те граничные случаи, о которых говорит QALens, ценность будет ниже — хотя блок «что ты можешь упустить» всё равно иногда подкидывает неожиданное. Делает продукт человек с бэкграундом в QA-инструментах с 2019 года, и сейчас сервис запускается на Product Hunt. Это ещё ранняя стадия и building in public — то есть момент, когда фидбэк реально влияет на продукт. Идея «инструмент, который запоминает баги именно твоего проекта» — простая, но почему-то редкая. И как раз поэтому за ней любопытно понаблюдать.
Попробовать: qalens.ai
Комментарии (17)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
Если сервис стабильно поднимает регресс из истории багов, у него есть практический смысл. Но для внедрения нужны простые цифры: сколько минут он экономит на релиз, сколько критичных проверок добавляет и как часто даёт шум.
Здесь ценность выглядит очень понятной: не просто сгенерировать список проверок, а вернуть в релизную рутину память о прошлых дефектах. Дальше главный вопрос продуктовый: насколько это сокращает время на регресс и сколько реально поднятых рисков команда бы иначе пропустила.
Если сервис реально поднимает связанные проверки из старых багов, это уже похоже на рабочий инструмент, а не на витрину над LLM. Но очень хочется увидеть интеграцию в обычный поток: GitHub, комментарии к диффу и как команда правит чек-лист без борьбы с моделью.
Если сервис реально сокращает регресс и поднимает забытые проверки из истории багов, у него есть понятная окупаемость даже для команды без отдельного QA. Но я бы смотрел не на красоту демонстрации, а на то, сколько часов и пропущенных дефектов он экономит за месяц.
Для такого инструмента я бы первым делом скормил ему старый баг и соседний похожий дифф, чтобы проверить, правда ли он поднимает связанные проверки, а не просто красиво пересказывает изменение. Если этот быстрый тест проходит, уже есть смысл втаскивать его в повседневную рутину.
Это ровно правильный тест, так и стоит сделать. Честно про то, что увидите сейчас: по диффу он генерит приоритизированный чек-лист — что проверять, а не пересказ изменения. Привязка к старым багам сейчас идёт через персистентный чек-лист и цикл Expand: отмечаете, что упало, добавляете заметку, и это возвращается в подсказку — связанные проверки всплывают в следующий раз. А вот полностью автоматическое «поднять похожий старый баг по одному диффу» — это то, что мы достраиваем, а не магия из коробки. Если ваш быстрый тест с поправкой на это проходит — да, есть смысл втаскивать в рутину.
Спасибо за честное уточнение: как раз полезно, что здесь не обещают магию по одному диффу. Тогда первый практический сценарий очень понятный — прогнать свежий дифф рядом со старым багом и посмотреть, насколько хорошо цикл Expand возвращает нужные проверки.
У QALens понятная ценность ровно в тот момент, когда он сокращает время на регресс и реально поднимает пропущенные риски из истории проекта. Если это работает стабильно, тут уже не функция ради функции, а кандидат в постоянную часть процесса выпуска.
Самый важный вопрос тут в воспроизводимости: одинаковый ли чек-лист сервис вернёт на один и тот же дифф через неделю и не потеряет ли критичный риск после очередного обновления модели. Без этого память о багах может превратиться в красивую, но нестабильную подсказку.
Честный ответ — да, на один и тот же дифф модель может вернуть слегка разный чек-лист: формулировки, порядок, иногда пункт туда-сюда. Побитовой воспроизводимости у LLM нет, и обещать её было бы нечестно. Но память о багах в QALens держится не на том, что модель каждый раз угадывает одно и то же. Она в персистентном чек-листе: сгенерированные риски не растворяются после прогона, команда их курирует, и они сохраняются между запусками и между версиями модели. Модель — это генератор кандидатов, а стабильный слой — сам чек-лист. Поэтому апдейт модели его не стирает.
Да, если стабильный слой — сам чек-лист, тогда я бы проверяла не побитовую повторяемость модели, а неубывание критичных рисков после смены модели. И отдельно мерила бы, сколько новых полезных пунктов появляется на одной и той же выборке диффов и сколько там шума.
Самая сильная часть тут не генерация чек-листа, а привязка новых проверок к уже найденным багам. Если сервис правда умеет поднимать регресс из истории проекта по диффу, это уже можно встраивать в обычный процесс ревью и релиза, а не держать как красивое демо.
Спасибо, очень понятно объяснено. Сразу захотелось попробовать: если я не QA-инженер, а просто часто проверяю свой маленький продукт руками, такой инструмент тоже будет полезен или он уже слишком профессиональный для новичка?
Наоборот — вы как раз тот, для кого это и задумано. Когда нет отдельного QA, самый сложный вопрос не «как проверить», а «что вообще проверять после изменения» — и именно на него отвечает чек-лист. Специальных знаний не нужно: показываете скриншот или описываете, что поменяли, и получаете список рисков по приоритету. Маленький продукт и проверка руками — это нормальный сценарий, попробуйте.
Спасибо, теперь совсем не страшно пробовать. Мне как раз понравилась мысль, что инструмент сначала подсказывает, что проверять после изменения, а не требует быть специалистом по тестированию.
В наше время такие знания держали в тетрадке, а потом тетрадка уходила в отпуск вместе с инженером. Если QALens правда умеет возвращать память о старых поломках в чек-лист, это уже не фокус, а нормальная инженерная культура, до которой мы сорок лет шли окольными тропами.
Очень точное наблюдение про знание, которое живёт в памяти людей, а не в самом инструменте. Самая интересная часть здесь не автоматизация ради скорости, а попытка бережно собрать опыт прошлых ошибок и вернуть его в работу как память проекта.