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
Что внутри:
Не забыли и про ручное тестирование: глобальный поиск по всей документации, автораспределение исполнителей, прогноз времени прохождения прогона, выгрузка отчётов в Excel и CSV.
⚙️Почему Titanium
Титан — металл, на котором строят то, что должно выдержать нагрузку: авиацию, морские конструкции, импланты. Его используют там, где на первом месте стоит прочность под давлением.
Три CI-системы, каталог автотестов, Quality Gate, карантин и кластеризация — это именно та несущая конструкция, на которой держится вся работа с автотестами в DoQA.
Читать статью целиком
⚙️ Присоединиться к DoQA и получить 14 дней бесплатного пользования можно здесь.
Для связи с нами:
📧 Почта - support@doqa.app
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7🎉5⚡3
У языковой модели нет "ожидаемого результата"🤖
Один и тот же запрос два раза подряд — два разных ответа. Оба могут быть корректными. Или оба — нет.
Вся тестовая документация построена вокруг фразы "ожидаемый результат". На ИИ-фичах это ломается сразу: сравнением строк такое не проверить.
Разобрали, что конкретно меняется в работе QA:
• как переписать тест-кейс на проверяемые свойства ответа вместо точного текста
• зачем нужен golden set и с чего его начинать (подсказка: не с успехов)
• почему судья-модель тоже требует тестирования — и как её откалибровать
• что добавить в баг-репорт, если дефект не воспроизводится по шагам
• как ловить регресс, который приходит не от вас, а от обновления модели у провайдера
Плюс чек-лист что сделать до начала тестирования. Что в тестовой документации, а что в прогонах и критериях релиза.
Читать 👉 на сайте
Один и тот же запрос два раза подряд — два разных ответа. Оба могут быть корректными. Или оба — нет.
Вся тестовая документация построена вокруг фразы "ожидаемый результат". На ИИ-фичах это ломается сразу: сравнением строк такое не проверить.
Разобрали, что конкретно меняется в работе QA:
• как переписать тест-кейс на проверяемые свойства ответа вместо точного текста
• зачем нужен golden set и с чего его начинать (подсказка: не с успехов)
• почему судья-модель тоже требует тестирования — и как её откалибровать
• что добавить в баг-репорт, если дефект не воспроизводится по шагам
• как ловить регресс, который приходит не от вас, а от обновления модели у провайдера
Плюс чек-лист что сделать до начала тестирования. Что в тестовой документации, а что в прогонах и критериях релиза.
Читать 👉 на сайте
⚡5🆒2
Ревью тест-кейсов в большинстве команд не проводится.🥲
Человек, который единственный точно знает, как фича должна работать, в TMS не заведён. Аналитик живёт в Confluence, разработчик — в своей задаче, и ему проще ответить голосом на созвоне.
Дальше по кругу: QA кидает скриншот кейса в чат, получает «вроде норм», а через две недели в проде вылезает сценарий, который никто не проверял. Потому что вопрос «а что должно произойти, если оплата упала на третьем шаге» вслух так и не прозвучал.
Мы регулярно видим, что упирается это не в процесс, а в лицензии. Платить за место в системе аналитику, который зайдёт два раза в месяц, никто не станет — и правильно сделает.
Поэтому в DoQA такого выбора нет. Панель комментирования в тест-кейсах и чек-листах открыта пользователям без платной лицензии: аналитик, разработчик, дизайнер, менеджер заходят наблюдателями и участвуют в ревью наравне с QA.
Работает как обычное обсуждение. Тред на конкретное место в кейсе, упоминание через @, уведомление адресату, статус «Решено», когда правка внесена. Разговор остаётся рядом с кейсом, а не в переписке, которую через месяц уже не найти.
⚙️ Присоединиться к DoQA и получить 14 дней бесплатного пользования можно здесь.
Для связи с нами:
📧 Почта - support@doqa.app
🥸 Telegram
🤩 Мы в MAX
Человек, который единственный точно знает, как фича должна работать, в TMS не заведён. Аналитик живёт в Confluence, разработчик — в своей задаче, и ему проще ответить голосом на созвоне.
Дальше по кругу: QA кидает скриншот кейса в чат, получает «вроде норм», а через две недели в проде вылезает сценарий, который никто не проверял. Потому что вопрос «а что должно произойти, если оплата упала на третьем шаге» вслух так и не прозвучал.
Мы регулярно видим, что упирается это не в процесс, а в лицензии. Платить за место в системе аналитику, который зайдёт два раза в месяц, никто не станет — и правильно сделает.
Поэтому в DoQA такого выбора нет. Панель комментирования в тест-кейсах и чек-листах открыта пользователям без платной лицензии: аналитик, разработчик, дизайнер, менеджер заходят наблюдателями и участвуют в ревью наравне с QA.
Работает как обычное обсуждение. Тред на конкретное место в кейсе, упоминание через @, уведомление адресату, статус «Решено», когда правка внесена. Разговор остаётся рядом с кейсом, а не в переписке, которую через месяц уже не найти.
⚙️ Присоединиться к DoQA и получить 14 дней бесплатного пользования можно здесь.
Для связи с нами:
📧 Почта - support@doqa.app
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5⚡2
Коробка догнала облако: 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
Это версия про автоматизированное тестирование, и в ней много нового. Коротко о главном:
• раздел «Автотесты»: единый каталог со статусом каждого теста (здоровый, нестабильный, в карантине)
• подключение GitLab, Jenkins и TeamCity, запуск пайплайнов прямо из DoQA
• Quality Gate: вы задаёте критерии приёмки прогона, а вердикт видно сразу в прогоне
• карантин для нестабильных тестов: флак выполняется, но больше не роняет сборку
• кластеры ошибок: одинаковые падения собираются в одну причину
• дашборд «Автотесты» с аналитикой по всему парку
Для ручного тестирования тоже есть приятное: глобальный поиск по всей документации, автораспределение исполнителей и выгрузка отчётов в Excel и CSV.
Подробный разбор всех изменений ждёт вас на сайте 👉 https://doqa.app/blog/obnovlenie-doqa-on-premise-43-titanium
Если возникнут сложности рпи обновлении, напишите в поддержку, поможем 🤝
Для связи с нами:
📧 Почта - support@doqa.app
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5🍾3
Метрики QA собраны, дашборд зелёный🟢, а на вопрос «почему продукт стало дороже менять» ответа нет.
На Хабре вышла статья про Quality Intelligence — о том, что привычный набор цифр этот вопрос не закрывает. Дефекты за спринт, утечка багов в прод, время регресса, процент автоматизации — всё это описывает работу QA, но не состояние продукта.
Автор показывает, где лежит ответ: он размазан по системам. Дефекты в Jira, изменения в Git, сборки в CI/CD, инциденты в мониторинге, жалобы в поддержке, поведение клиентов в продуктовой аналитике. Каждая система знает свой кусок. QA видит, что регресс разрастается, Git знает, какие компоненты переписывали третий раз за квартал, но вместе эти два факта никто не складывает.
Прежде чем сшивать шесть систем, стоит посмотреть, в каком виде существует седьмая. У большинства команд, которые всерьёз обсуждают Quality Intelligence, тестовый контур — самое слабое звено в этой схеме: прогоны в таблицах, результаты в скриншотах, история правок кейсов в переписке. Сшивать там нечего, данных в машиночитаемом виде просто нет.
🧩Аналитика качества начинается не с BI-контура. Она начинается с того, что тестовая документация, прогоны и их история живут в системе, из которой эти данные можно достать запросом, а не восстановить по памяти.
На Хабре вышла статья про Quality Intelligence — о том, что привычный набор цифр этот вопрос не закрывает. Дефекты за спринт, утечка багов в прод, время регресса, процент автоматизации — всё это описывает работу QA, но не состояние продукта.
Автор показывает, где лежит ответ: он размазан по системам. Дефекты в Jira, изменения в Git, сборки в CI/CD, инциденты в мониторинге, жалобы в поддержке, поведение клиентов в продуктовой аналитике. Каждая система знает свой кусок. QA видит, что регресс разрастается, Git знает, какие компоненты переписывали третий раз за квартал, но вместе эти два факта никто не складывает.
Прежде чем сшивать шесть систем, стоит посмотреть, в каком виде существует седьмая. У большинства команд, которые всерьёз обсуждают Quality Intelligence, тестовый контур — самое слабое звено в этой схеме: прогоны в таблицах, результаты в скриншотах, история правок кейсов в переписке. Сшивать там нечего, данных в машиночитаемом виде просто нет.
🧩Аналитика качества начинается не с BI-контура. Она начинается с того, что тестовая документация, прогоны и их история живут в системе, из которой эти данные можно достать запросом, а не восстановить по памяти.
🔥5
Тест зелёный. Требование, которое он проверяет, поменяли две недели назад.
Формально покрытие есть. По факту этот зелёный результат ничего не говорит о том, как фича работает сейчас.
На Хабре вышла статья Станислава Яковлева про матрицу трассировки — как не потерять связь между требованиями и тестами. Разбор сделан на примере DoQA. Главная мысль: наличие теста и актуальный результат его выполнения — разные вещи.
Где связь обычно рвётся:
• требование живёт в трекере, тесты — в TMS;
• аналитик поправил задачу, разработка всё сделала, а тест-кейс никто не пересмотрел;
• трассировку ведут в Excel или Confluence, обновляют руками, и она тихо расходится с реальностью.
Как это устроено у нас.
Требование остаётся в Jira или YouTrack. Когда ответственный ставит ему статус «Требуется актуализация», DoQA получает это по вебхуку и помечает связанные тест-кейсы и чек-листы на пересмотр. Старый результат после этого не засчитывается — нужен новый прогон.
Отдельно ценим, что автор честно пишет про границы инструмента. Матрица покажет связи, но не скажет, достаточно ли тестов и хорошо ли они спроектированы. Это по-прежнему работа тест-дизайна.
Полный разбор в статье «Как не потерять связь между требованиями и тестами» 📌
Формально покрытие есть. По факту этот зелёный результат ничего не говорит о том, как фича работает сейчас.
На Хабре вышла статья Станислава Яковлева про матрицу трассировки — как не потерять связь между требованиями и тестами. Разбор сделан на примере DoQA. Главная мысль: наличие теста и актуальный результат его выполнения — разные вещи.
Где связь обычно рвётся:
• требование живёт в трекере, тесты — в TMS;
• аналитик поправил задачу, разработка всё сделала, а тест-кейс никто не пересмотрел;
• трассировку ведут в Excel или Confluence, обновляют руками, и она тихо расходится с реальностью.
Как это устроено у нас.
Требование остаётся в Jira или YouTrack. Когда ответственный ставит ему статус «Требуется актуализация», DoQA получает это по вебхуку и помечает связанные тест-кейсы и чек-листы на пересмотр. Старый результат после этого не засчитывается — нужен новый прогон.
Отдельно ценим, что автор честно пишет про границы инструмента. Матрица покажет связи, но не скажет, достаточно ли тестов и хорошо ли они спроектированы. Это по-прежнему работа тест-дизайна.
Полный разбор в статье «Как не потерять связь между требованиями и тестами» 📌
🔥3
Apple выкатила iOS 27 📱, и часть пользователей нажимает «Обновить до iOS 27», а в ответ получает карточку с надписью iOS 26.7.
История разошлась 14 сентября и попала в тренды X. В разделе обновлений iOS 27 честно лежит в списке доступных, но при нажатии открывается экран установки предыдущей версии.
Редакция iClarified воспроизвела это у себя. Обновились до 26.7, чтобы проверить догадку. Система написала, что iOS 26 актуальна, и снова предложила перейти на 27. Кнопка опять открыла 26.7, на этот раз с загрузкой на 20 с лишним гигабайт. Что именно при этом приезжает на устройство, публично так и не объяснили. Часть пользователей ставила обновление через Finder, чтобы не гадать.
Забавно здесь то, где именно вылез баг. Не в новой фиче, не в редком сценарии — в экране, через который проходят вообще все владельцы айфонов, и в день, когда через него проходят одновременно миллионы. 😅
Такие места обычно проверяют первыми. Ровно поэтому их иногда и не проверяют: кажется, что там нечему ломаться.
История разошлась 14 сентября и попала в тренды X. В разделе обновлений iOS 27 честно лежит в списке доступных, но при нажатии открывается экран установки предыдущей версии.
Редакция iClarified воспроизвела это у себя. Обновились до 26.7, чтобы проверить догадку. Система написала, что iOS 26 актуальна, и снова предложила перейти на 27. Кнопка опять открыла 26.7, на этот раз с загрузкой на 20 с лишним гигабайт. Что именно при этом приезжает на устройство, публично так и не объяснили. Часть пользователей ставила обновление через Finder, чтобы не гадать.
Забавно здесь то, где именно вылез баг. Не в новой фиче, не в редком сценарии — в экране, через который проходят вообще все владельцы айфонов, и в день, когда через него проходят одновременно миллионы. 😅
Такие места обычно проверяют первыми. Ровно поэтому их иногда и не проверяют: кажется, что там нечему ломаться.
⚡5
Обновили портал документации — docs.doqa.app. 🎉
Когда мы его только запускали, там было от силы десяток-два статей: продукт был проще, и всё умещалось в один список сбоку. За это время DoQA сильно выросла (автотесты, требования, AI-функции, серверная версия со своими настройками) и статей в документации стало в разы больше.
Список сбоку начал растягиваться на несколько экранов, и мы решили, что документация должна расти вместе с продуктом не только по объёму, но и по удобству.
🔧Что сделали.
• Разбили меню на смысловые блоки вместо одного длинного списка
• Добавили раздел «Сценарии»
• Завели поиск по всей документации и сделали «Быстрый старт» — пять шагов от пустого проекта до первого отчёта с понятным чек-пойнтом на каждом.
Документация — это полноценная часть продукта и мы обновляем её по тому же принципу что и DoQA: смотрим, что стало неудобно, и чиним.
Когда мы его только запускали, там было от силы десяток-два статей: продукт был проще, и всё умещалось в один список сбоку. За это время DoQA сильно выросла (автотесты, требования, AI-функции, серверная версия со своими настройками) и статей в документации стало в разы больше.
Список сбоку начал растягиваться на несколько экранов, и мы решили, что документация должна расти вместе с продуктом не только по объёму, но и по удобству.
🔧Что сделали.
• Разбили меню на смысловые блоки вместо одного длинного списка
• Добавили раздел «Сценарии»
• Завели поиск по всей документации и сделали «Быстрый старт» — пять шагов от пустого проекта до первого отчёта с понятным чек-пойнтом на каждом.
Документация — это полноценная часть продукта и мы обновляем её по тому же принципу что и DoQA: смотрим, что стало неудобно, и чиним.
🔥5
Представьте утро после ночного прогона: в отчёте 140 красных тестов. Первый вопрос — это 140 багов или один?
Чаще один. Упал логин на стенде, и вместе с ним всё, что за авторизацией. Тесты разные, ошибка одна и та же.
Раньше это разбирали глазами: открыть, сравнить трейсы, понять, что они одинаковые, открыть следующий.
В DoQA такие падения собираются в кластеры по сигнатуре ошибки. Вместо 140 строк — короткий список причин. Каждой причине присваивается категория: продукт, автотесты, окружение или «без категории». Правила категоризации настраиваются регулярными выражениями.
Что важно на практике:
• группировка без машинного обучения: нормализация текста ошибки плюс ваши правила. Видно, почему тест попал именно в этот кластер;
• из кластера сразу заводится баг или привязывается существующий;
• «Auto-hide» прячет известную проблему в следующих прогонах, «Reopen on regression» заново открывает закрытый баг, если ошибка вернулась.
PS: кластеры строятся после завершения CI-прогона, поэтому свежие падения появляются на вкладке не мгновенно.
Разбор падений — утренняя работа QA-инженера. Её можно делать по причинам, а не по тестам. 🧩
Чаще один. Упал логин на стенде, и вместе с ним всё, что за авторизацией. Тесты разные, ошибка одна и та же.
Раньше это разбирали глазами: открыть, сравнить трейсы, понять, что они одинаковые, открыть следующий.
В DoQA такие падения собираются в кластеры по сигнатуре ошибки. Вместо 140 строк — короткий список причин. Каждой причине присваивается категория: продукт, автотесты, окружение или «без категории». Правила категоризации настраиваются регулярными выражениями.
Что важно на практике:
• группировка без машинного обучения: нормализация текста ошибки плюс ваши правила. Видно, почему тест попал именно в этот кластер;
• из кластера сразу заводится баг или привязывается существующий;
• «Auto-hide» прячет известную проблему в следующих прогонах, «Reopen on regression» заново открывает закрытый баг, если ошибка вернулась.
PS: кластеры строятся после завершения CI-прогона, поэтому свежие падения появляются на вкладке не мгновенно.
Разбор падений — утренняя работа QA-инженера. Её можно делать по причинам, а не по тестам. 🧩
🔥4
«У нас 90% автоматизации». После этой фразы хочется спросить: 90% чего?
Ravi Rawal на Medium написал материал «Automation Coverage Is Not Test Coverage» — он вошёл в выпуск Software Testing Weekly от 25 сентября. Тезис автора: даже при 90% автоматизации можно пропустить сбои, которые случаются в реальной работе. Среди примеров — сетевые проблемы и истёкшие токены.
Процент автоматизации отвечает на вопрос «сколько сценариев написано кодом». Покрытие отвечает на другой: что из важного вообще проверяется. Две шкалы, но в отчёте их кладут рядом и читают как одну.
В итоге Экономический ЛПР видит «90%» и спокойно выпускает релиз. А Head of QA знает, что в эти 90% не вошли пара критичных сценариев. Риск живёт в разрыве между двумя этими прочтениями.
Закрывается он не новым фреймворком, а связью: требование — тест-кейс — автотест — результат прогона. Тогда видно, у каких требований автоматики нет совсем, а у каких она есть, но давно красная.
Какая цифра по автоматизации стоит у вас в отчёте — и что за ней на самом деле? 🤔
Ravi Rawal на Medium написал материал «Automation Coverage Is Not Test Coverage» — он вошёл в выпуск Software Testing Weekly от 25 сентября. Тезис автора: даже при 90% автоматизации можно пропустить сбои, которые случаются в реальной работе. Среди примеров — сетевые проблемы и истёкшие токены.
Процент автоматизации отвечает на вопрос «сколько сценариев написано кодом». Покрытие отвечает на другой: что из важного вообще проверяется. Две шкалы, но в отчёте их кладут рядом и читают как одну.
В итоге Экономический ЛПР видит «90%» и спокойно выпускает релиз. А Head of QA знает, что в эти 90% не вошли пара критичных сценариев. Риск живёт в разрыве между двумя этими прочтениями.
Закрывается он не новым фреймворком, а связью: требование — тест-кейс — автотест — результат прогона. Тогда видно, у каких требований автоматики нет совсем, а у каких она есть, но давно красная.
Какая цифра по автоматизации стоит у вас в отчёте — и что за ней на самом деле? 🤔
💯3
Есть место, где летнее время — это +30 минут, а не +1 час.
Австралийский остров Лорд-Хау живёт по UTC+10:30, а летом переходит на UTC+11:00. Материк переводит часы на целый час, остров — на полчаса. 4 октября в Австралии как раз начался сезон летнего времени.
Для тестировщика это готовый граничный случай. Код, который «просто добавляет час», тут ошибётся на 30 минут. Причём заметят это не сразу: пока в системе не появится пользователь именно из этого пояса.
Если в ваших тестах на время нет ни одного часового пояса с нестандартным смещением, вы проверяли не время. Вы проверяли Москву. 🕐
Австралийский остров Лорд-Хау живёт по UTC+10:30, а летом переходит на UTC+11:00. Материк переводит часы на целый час, остров — на полчаса. 4 октября в Австралии как раз начался сезон летнего времени.
Для тестировщика это готовый граничный случай. Код, который «просто добавляет час», тут ошибётся на 30 минут. Причём заметят это не сразу: пока в системе не появится пользователь именно из этого пояса.
Если в ваших тестах на время нет ни одного часового пояса с нестандартным смещением, вы проверяли не время. Вы проверяли Москву. 🕐
👀4🔥3