DoQA

Apple выкатила iOS 27 📱, и часть пользователей нажимает «Обновить до iOS 27», а в ответ получает карточку с надписью iOS 26.7.

История разошлась 14 сентября и попала в тренды X. В разделе обновлений iOS 27 честно лежит в списке доступных, но при нажатии открывается экран установки предыдущей версии.

Редакция iClarified воспроизвела это у себя. Обновились до 26.7, чтобы проверить догадку. Система написала, что iOS 26 актуальна, и снова предложила перейти на 27. Кнопка опять открыла 26.7, на этот раз с загрузкой на 20 с лишним гигабайт. Что именно при этом приезжает на устройство, публично так и не объяснили. Часть пользователей ставила обновление через Finder, чтобы не гадать.

Забавно здесь то, где именно вылез баг. Не в новой фиче, не в редком сценарии — в экране, через который проходят вообще все владельцы айфонов, и в день, когда через него проходят одновременно миллионы. 😅

Такие места обычно проверяют первыми. Ровно поэтому их иногда и не проверяют: кажется, что там нечему ломаться.

Тест зелёный. Требование, которое он проверяет, поменяли две недели назад.

Формально покрытие есть. По факту этот зелёный результат ничего не говорит о том, как фича работает сейчас.

На Хабре вышла статья Станислава Яковлева про матрицу трассировки — как не потерять связь между требованиями и тестами. Разбор сделан на примере DoQA. Главная мысль: наличие теста и актуальный результат его выполнения — разные вещи.

Где связь обычно рвётся:
• требование живёт в трекере, тесты — в TMS;
• аналитик поправил задачу, разработка всё сделала, а тест-кейс никто не пересмотрел;
• трассировку ведут в Excel или Confluence, обновляют руками, и она тихо расходится с реальностью.

Как это устроено у нас.
Требование остаётся в Jira или YouTrack. Когда ответственный ставит ему статус «Требуется актуализация», DoQA получает это по вебхуку и помечает связанные тест-кейсы и чек-листы на пересмотр. Старый результат после этого не засчитывается — нужен новый прогон.

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

Полный разбор в статье «Как не потерять связь между требованиями и тестами» 📌

Метрики QA собраны, дашборд зелёный🟢, а на вопрос «почему продукт стало дороже менять» ответа нет.

На Хабре вышла статья про Quality Intelligence — о том, что привычный набор цифр этот вопрос не закрывает. Дефекты за спринт, утечка багов в прод, время регресса, процент автоматизации — всё это описывает работу QA, но не состояние продукта.

Автор показывает, где лежит ответ: он размазан по системам. Дефекты в Jira, изменения в Git, сборки в CI/CD, инциденты в мониторинге, жалобы в поддержке, поведение клиентов в продуктовой аналитике. Каждая система знает свой кусок. QA видит, что регресс разрастается, Git знает, какие компоненты переписывали третий раз за квартал, но вместе эти два факта никто не складывает.

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

🧩Аналитика качества начинается не с BI-контура. Она начинается с того, что тестовая документация, прогоны и их история живут в системе, из которой эти данные можно достать запросом, а не восстановить по памяти.

Коробка догнала облако: DoQA On-Premise 4.3 (Titanium) уже доступна 🎉

Это версия про автоматизированное тестирование, и в ней много нового. Коротко о главном:

• раздел «Автотесты»: единый каталог со статусом каждого теста (здоровый, нестабильный, в карантине)
• подключение GitLab, Jenkins и TeamCity, запуск пайплайнов прямо из DoQA
• Quality Gate: вы задаёте критерии приёмки прогона, а вердикт видно сразу в прогоне
• карантин для нестабильных тестов: флак выполняется, но больше не роняет сборку
• кластеры ошибок: одинаковые падения собираются в одну причину
• дашборд «Автотесты» с аналитикой по всему парку

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

Подробный разбор всех изменений ждёт вас на сайте 👉 https://doqa.app/blog/obnovlenie-doqa-on-premise-43-titanium

Если возникнут сложности рпи обновлении, напишите в поддержку, поможем 🤝

Для связи с нами:
📧 Почта - support@doqa.app
🥸 Telegram
🤩 Мы в MAX

Ревью тест-кейсов в большинстве команд не проводится.🥲

Человек, который единственный точно знает, как фича должна работать, в TMS не заведён. Аналитик живёт в Confluence, разработчик — в своей задаче, и ему проще ответить голосом на созвоне.

Дальше по кругу: QA кидает скриншот кейса в чат, получает «вроде норм», а через две недели в проде вылезает сценарий, который никто не проверял. Потому что вопрос «а что должно произойти, если оплата упала на третьем шаге» вслух так и не прозвучал.

Мы регулярно видим, что упирается это не в процесс, а в лицензии. Платить за место в системе аналитику, который зайдёт два раза в месяц, никто не станет — и правильно сделает.

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

Работает как обычное обсуждение. Тред на конкретное место в кейсе, упоминание через @, уведомление адресату, статус «Решено», когда правка внесена. Разговор остаётся рядом с кейсом, а не в переписке, которую через месяц уже не найти.

⚙️ Присоединиться к DoQA и получить 14 дней бесплатного пользования можно здесь.

Для связи с нами:
📧 Почта - support@doqa.app
🥸 Telegram
🤩 Мы в MAX

У языковой модели нет "ожидаемого результата"🤖

Один и тот же запрос два раза подряд — два разных ответа. Оба могут быть корректными. Или оба — нет.

Вся тестовая документация построена вокруг фразы "ожидаемый результат". На ИИ-фичах это ломается сразу: сравнением строк такое не проверить.

Разобрали, что конкретно меняется в работе QA:

• как переписать тест-кейс на проверяемые свойства ответа вместо точного текста
• зачем нужен golden set и с чего его начинать (подсказка: не с успехов)
• почему судья-модель тоже требует тестирования — и как её откалибровать
• что добавить в баг-репорт, если дефект не воспроизводится по шагам
• как ловить регресс, который приходит не от вас, а от обновления модели у провайдера

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

Читать 👉 на сайте

DoQA 4.3 (Titanium) — самый крупный релиз для автоматизированного тестирования

Что внутри:

☑️ Раздел «Автотесты». Единый каталог всех автотестов пространства с деревом структуры и фильтрами по ветке, тегам, источнику и карантину. У каждого теста — понятное состояние: здоровый, нестабильный, сломанный, в карантине.

☑️ Запуск в CI/CD. Подключение к GitLab, Jenkins и TeamCity. Один прогон может держать сразу несколько пайплайнов — разнородный набор автотестов разбивается на группы и закрывается, когда завершился последний из них.

☑️ Quality Gate. Задаёте критерии, при которых прогон считается пройденным: доля успешных тестов, предельное число падений, обязательные окружения. Никакого «позеленения» прогона за счёт повторов — а команда doqactl gate возвращает вердикт прямо в пайплайн.

☑️ Карантин нестабильных тестов. DoQA сама находит флак по истории прогонов — разный исход на одном коммите, «прошёл со второй попытки». Нестабильный тест уходит в карантин: продолжает выполняться, но больше не роняет пайплайн. Как только тест успокоился — карантин снимается автоматически.

☑️ Кластеры ошибок. Падения с одинаковой причиной группируются в один кластер по сигнатуре ошибки. Кластер можно отметить известной проблемой — она перестаёт шуметь в отчётах и открывается заново только при реальном регрессе.

☑️ Дашборд «Автотесты». Доля автоматизации, здоровье парка тестов, топ падающих тестов, экономия времени CI — всё в одной вкладке аналитики.

☑️ Адаптеры и IDE. JUnit 5, JUnit 4, TestNG, PyTest отправляют результаты в DoQA без файлового отчёта. Плагины для IntelliJ IDEA и VS Code показывают привязку теста к кейсу прямо в редакторе.

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

⚙️Почему Titanium

Титан — металл, на котором строят то, что должно выдержать нагрузку: авиацию, морские конструкции, импланты. Его используют там, где на первом месте стоит прочность под давлением.

Три CI-системы, каталог автотестов, Quality Gate, карантин и кластеризация — это именно та несущая конструкция, на которой держится вся работа с автотестами в DoQA.

Читать статью целиком ➡️ https://clck.ru/3Vwv8u

⚙️ Присоединиться к DoQA и получить 14 дней бесплатного пользования можно здесь.

Для связи с нами:
📧 Почта - support@doqa.app
🥸 Telegram
🤩 Мы в MAX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем привет 👋

Пока допиливаем большой блок автотестов, добавили в текущую DoQA 4.2 Niccolum (для облака и коробки) доработку по запросу клиента.

У многих команд в Kaiten настроены свои кастомные поля - приоритет, компонент, окружение и т.д..
Многие из вас об этом писали: баг-репорт из DoQA долетал до Kaiten, а поля оставались пустыми - их приходилось дозаполнять руками уже в самом трекере.

Теперь DoQA считывает кастомные поля Kaiten и даёт заполнить их сразу при создании баг-репорта не выходя из интерфейса DoQA.

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

🌐 https://doqa.app/
🥸 Telegram
🤩 Мы в MAX

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

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

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

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