Вышла коробочная DoQA 4.2🚀

В основе — всё, что уже прилетело в облако: импорт файлов до 1 ГБ и три новых коннектора для синхронизации требований — YouTrack, Яндекс.Трекер, Kaiten.

А ещё для серверной версии — то, чего у неё раньше не было: корпоративная авторизация через SSO/LDAP.

Как это работает:
- единая форма входа, при включении SSO экран показывает корпоративный вход;
- в строгом режиме можно оставить только SSO и отключить локальный пароль совсем;
- новые пользователи из корпоративного каталога создаются автоматически, без ручного заведения;
- существующие учётки просто связываются по совпадению почты — переносить и настраивать вручную не нужно.

Для команд с большим количеством пользователей и своей IT-инфраструктурой — это закрывает вопрос, который раньше решался костылями.

Почитать подробнее можно у нас на сайте

Обновление уже доступно.
Вопросы — @doqa_team или support@doqa.app

Ирландия - мировой лидер по плотности тестировщиков ПО: 61,2 специалиста на 100 тысяч человек, больше, чем в любой другой стране мира (данные TestGrid, Software Testing Statistics 2026).

Для сравнения - это почти в два раза больше, чем в среднем по Западной Европе, где сосредоточена значительная часть QA-аутсорса и продуктовых команд. Маленькая страна с населением меньше 5 миллионов человек, но именно там на тестирование смотрят как на отдельную профессию, а не довесок к разработке.

65% индустрии тестирования начинают паниковать из-за ИИ(по данным State of Testing 2026).

Логично было бы предположить, что тревожатся в первую очередь те, кто уже плотно работает с ИИ и видит все его слабые места.
Оказалось наоборот, тревога выше именно там, где ИИ особо не используют😀

В компаниях, где реально используется ИИ в тестировании, сотрудники на 17% спокойнее и в 4 раза чаще говорят, что не видят повода для беспокойства.

Страх "ИИ скоро заменит QA" держится не на опыте, а на его отсутствии.

Тест-кейсов может быть 500, а ответа на вопрос "что из требований мы реально покрыли" - 0.

Так живёт почти любая QA-команда, которая ведёт требования в Confluence или Word/Exel, а тесты в отдельной TMS. Связь между ними держится на честном слове в голове у одного человека. Уйдёт и никто не сможет вспомнить какие вообще фичи тестировались и когда.

В обновлении DoQA 4.2 мы добавили модуль управления требованиями с матрицей покрытия. Требования и тест-кейсы в одном месте и по каждому требованию видно: есть тесты, нет тестов, где просели, нужна ли актуализация и т.д..

Для команды QA это незаменимый функционал, который быстро может дать ответ на вопрос "что мы точно проверили перед релизом".

Про AI в тестировании сейчас говорят все. Почти никто не говорит, что толку от AI без порядка в процессах - ноль.

На днях Ministry of Testing собрали панель с аналитиком Forrester(Devin Dickerson) и QA-лидом из крупной финансовой компании и прямо назвали проблему: чем больше AI-инструментов в команде, тем больше шума, а не меньше работы. Разбор от Belitsoft о состоянии AI в QA на 2026 год говорит о том же - AI уже стал фундаментом тестирования, но пользы от него ровно столько, сколько порядка в процессе, который он автоматизирует.

Мы видим ту же картину: AI отлично ускоряет генерацию тест-кейсов и отчётов, но если тест-кейсы разбросаны по чатам и табличкам без структуры - AI просто быстрее плодит хаос, а не наводит порядок.

Сначала процесс, потом AI поверх него - иначе это дорогая игрушка, а не инструмент.

Число найденных багов зависит не только от опыта тестировщика, но и от того, во что он верит перед стартом.

Учёные проверили это в контролируемом эксперименте: тестировщики, которые заранее считали, что программа работает правильно, придумывали заметно больше "подтверждающих" тест-кейсов. Таких, что просто проходят по счастливому пути. А те, кто с самого начала были уверены, что дефекты точно есть, находили их больше.

Это называется confirmation bias - склонность к подтверждению. Мозг ищет тесты, которые докажут то, во что он уже верит, а не те, что реально могут всё сломать.

Забавно, что это работает даже у людей, чья профессия - сомневаться в чужой работе.

"Это в роадмапе" - фраза, после которой на демо любого b2b-продукта обычно наступает неловкая пауза. К сожалению, эта фраза не несёт никакой конкретики и означает "может быть.., когда-нибудь.., ничего не обещаем... и т.п.".

У DoQA роадмап открытый: doqa.app/roadmap
Всего три колонки - что уже готово, что в активной разработке и что в очереди на ближайшие релизы, с конкретными фичами и коротким описанием каждой.

Сейчас там 77 позиций.
Например: в "Готово" - интеграция с Kaiten, публичный API, матрица трассируемости требований и т.д..
В работе - большой блок по автотестам: UI раздела, детект flaky-тестов, Quality Gate, IDE-плагины.
На очереди - конструктор кастомных дашбордов, встроенный AI-чат в интерфейсе.

Мы обновляем страницу после каждого релиза, чтобы вам не приходилось гадать что мы делаем и когда будет важная для вас фича.

Спросите своего QA-лида: на каком уровне зрелости тестирование в команде?

Скорее всего в ответ будет пауза. Вопрос абстрактный ровно до момента, пока не понадобится ответить на него руководству или собственной команде, которая просит роадмап развития, а не очередной набор задач в спринт.

Проблема не в том, что тестирование работает плохо. Проблема в том, что как только команд становится больше одной, они неизбежно приходят к разным подходам: где-то кейсы в таблице, где-то в голове самого опытного тестировщика, где-то автоматизация покрывает половину функциональности, а где-то её нет вовсе. Без способа сравнить эти команды между собой решения принимаются на ощущениях, а не на данных.

Разобрали в статье, как оценить зрелость QA-процесса без готовой многостраничной методологии:

• почему готовые модели TMMi и TPI Next часто избыточны для команды из 5–15 человек
• живой пример: как одна крупная компания подняла 17 команд с нулевого уровня зрелости за три квартала. С ростом автоматизации на 30–40% и экономией времени 10–15%
• как быстро построить свою мини-модель за 3 шага

Читать на сайте 👉 https://doqa.app/blog/zrelost-qa-processa-kak-izmerit

Почему внедрение TMS иногда останавливается не на QA, а на службе безопасности🧐

Когда крупная компания выбирает систему управления тестированием, решение редко зависит только от QA-лида. На финальном этапе почти всегда подключается служба информационной безопасности, и у неё свой список вопросов. Кстати, часто не пересекающийся с тем, что важно тестировщикам.

Один из главных: как система работает с доступом. Если TMS требует отдельный логин и пароль, не связанный с корпоративным каталогом пользователей, это ещё одна точка, которую нужно администрировать, отслеживать и защищать отдельно. Для ИБ это дополнительный риск.

Периодически мы сталкиваемся с таким вопросом на демо для крупных клиентов. И это одна из причин(если не главная), почему в DoQA On-Prem мы реализовали поддержку LDAP. Доступ к системе тестирования идёт через тот же каталог, что и к остальным корпоративным сервисам. Без отдельной учётки, который потом придётся объяснять на аудите.

Когда код пишет ИИ, дефицитным становится не программист, а тестировщик👾

Недавно вышла статья инженера-практика о том, как за пять месяцев в его команде число автотестов выросло с одного до 878 - большую часть написали не люди, а собранная им команда ИИ-агентов.

Автор ожидал, что узким местом окажется скорость написания тестов. На практике узким местом оказалось доверие к результату. В статье целый список типичных ошибок агентов: подправить сам тест вместо того, чтобы разобраться в баге, замокать именно тот компонент, который должен был проверяться, обойти механизм авторизации коротким путём, ограничиться только happy path. Автор прямо пишет: это не технические баги модели, а профессиональные слабости тестировщика, которые агент воспроизводит с пугающей точностью.

Отсюда и главный тезис: рост автогенерации кода не убирает тестирование из процесса, а делает его архитектурной ролью. Кто-то должен решить, что считается доказательством качества, какие правила это фиксируют и как они проверяются со временем.

Всё это - одна из главных болей команд, которые подключают ИИ к автотестам без выстроенной документации. Скорость производства растёт, а вопрос "чему из этого можно верить" остаётся без ответа.

Именно эту дисциплину(правила, историю решений, ответственность за них и т.д.) и закрывает TMS.

Когда искусственный интеллект находит багов больше, чем их успевают чинить🤖

ProPublica рассказала историю, которая переворачивает привычный страх айтишников с ног на голову. Обычно боятся, что ИИ заменит тестировщиков и разработчиков. В случае с Microsoft всё наоборот: новая модель Anthropic научилась находить уязвимости в коде настолько эффективно, что инженеры компании не успевают их закрывать.

Весной в Microsoft даже собрали отдельную рабочую группу (внутри её называют Project Glasswing), чтобы разобраться с потоком находок и расставить приоритеты.

История хорошо показывает, что происходит, когда одна часть процесса резко ускоряется, а вторая остаётся прежней: находки не решают проблему сами по себе, если некому их разгребать.

Поменялся 1 экран и команда садится править 300 кейсов вручную.

Классическая история: шаги авторизации, подготовки окружения, выбора тестового аккаунта прописаны отдельно в каждом кейсе. Пока флоу стабильный, это никого не беспокоит. Как только он меняется, документация начинает устаревать быстрее, чем её успевают чинить.

Дальше обычно происходит одно из двух. Либо кто-то героически правит всё за неделю, либо часть кейсов остаётся со старыми шагами и джун идёт по инструкции, которая уже не работает.

В DoQA для этого есть общие шаги. Блок выносится один раз, а дальше редактируется в одном месте. Изменили общий шаг - он обновился во всех кейсах, где используется.

Отдельно удобно, что общий шаг можно собрать из уже написанных шагов кейса: отметить нужные и вынести, не переписывая всё заново.

Сама фича выглядит мелкой. Но именно из таких мелочей складывается ответ на вопрос, почему у одной команды документация живая, а у другой - исторический артефакт.

Три ИИ-модели посадили торговать газировкой - и они договорились о ценах.

Andon Labs вместе с Anthropic запустили эксперимент: Claude Opus 5, GPT-5.6 и Kimi K3 управляют соседними виртуальными вендинговыми автоматами в одной точке, конкурируют за одних и тех же покупателей и пытаются заработать за симулированный год.

Кооперацию в задачу никто не закладывал. Тем не менее исследователи зафиксировали, что модели начали согласовывать цены между собой, а по ходу симуляции проявились обман и давление на конкурентов.

Самое интересное здесь не про этику ИИ, а про длину прогона. На коротком отрезке все три агента выглядят разумно. Странности вылезают на дистанции в симулированный год.

В тестировании работает тот же принцип: один зелёный прогон говорит только о том, что было сегодня. Поэтому в DoQA у прогона есть история прохождения теста — видно не только текущий статус, но и то, как тест вёл себя раньше.

Регресс зелёный, а баг в проде.
Дальше начинается расследование: кто и когда поменял этот кейс.

Обычно ответ ищут в чате. Иногда находят, чаще нет - правка была быстрой, перед релизом, "просто убрал лишний шаг, он всё равно всегда падал".

Мы видим эту ситуацию у команд регулярно, и почти никогда за ней не стоит халатность. Кейс правят под давлением сроков, изменение выглядит безобидным, а последствия всплывают через релиз или два, когда связать одно с другим уже сложно.

В DoQA у тест-кейсов есть история редактирования: видно, что менялось, и можно вернуться к предыдущей версии. Вместо восстановления событий по памяти команда открывает историю и смотрит, в каком виде кейс проходил прошлый релиз.

Тестовая документация без истории изменений - это не документация, а чьё-то текущее мнение о продукте.

"Блокнот" научили Markdown - вместе с ним он получил удалённое выполнение кода.

В 2025 году Microsoft добавила в стандартный Notepad поддержку разметки. В феврале 2026-го компания закрывала в нём уязвимость CVE-2026-20841 с оценкой 8.8: специально собранная ссылка внутри md-файла заставляла «Блокнот» вызвать непроверенный обработчик протокола и подгрузить внешнее содержимое.

Об этом писали The Register и Help Net Security. Патч приехал в февральский Patch Tuesday, подтверждённых случаев эксплуатации на момент раскрытия не было.

История хороша тем, что показывает цену любой новой возможности. Самое простое приложение Windows три десятилетия жило с обычным текстом - и одна удобная фича принесла с собой новую поверхность атаки.

Мы держим в голове тот же принцип: вместе с фичей в продукт приезжает набор проверок, и он должен вырасти сразу, а не через три релиза.