IT Test

Тестирование было нашей ключевой экспертизой ещё до того, как мы начали разрабатывать сайты и мобильные приложения. Мы занимаемся этим достаточно давно, чтобы знать: тестировщикам не нужен ещё один красивый интерфейс - им нужно, чтобы рутина не съедала время и инструмент действительно помогал в работе. Именно это мы заложили в DoQA. Например, заголовок баг-репорта тестировщик обычно пишет на бегу, просто описывая, что получилось. DoQA сама формирует чёткий заголовок по описанию фактического результата - мелочь, но таких мелочей за день набирается на десятки багов. Или другая рутина: перечитывать свои же тест-кейсы на полноту и ясность формулировок. DoQA проверяет кейс на атомарность и на ясность цели. Если что-то не так, сразу предлагает правки которые можно применить одной кнопкой. Ещё одна вечная головная боль QA-лида - доказать, что команда протестировала именно то, что должна была, а не просто накопила гору тест-кейсов. Требования живут в трекере, тесты - в TMS, и без ручной сверки понять реальное покрытие почти невозможно. В DoQA есть матрица трассировки: она напрямую связывает требования из Jira с тест-кейсами и результатами прогонов, показывает, что осталось непокрытым, а если требование поменялось - помечает связанные тесты статусом «требуется актуализация», чтобы старый результат не вводил в заблуждение. Документация и подробности на сайте doqa.app

"Отдать разработку на аутсорс - значит потерять контроль над проектом". Один из самых живучих мифов у заказчиков. На практике контроль теряют не из-за формата работы, а из-за того, как он выстроен: • нет регулярных демо и статус-встреч, поэтому о состоянии проекта вы узнаёте по факту, а не заранее; • нет доступа к беклогу и трекеру задач, поэтому непонятно, что вообще происходит между созвонами; • архитектурные решения принимаются без согласования, и вы узнаёте узнаёт о них, когда переделывать уже поздно; • отчётность даётся «по запросу», а не по согласованному графику, поэтому спрашивать приходится самому. Знакомая ситуация: спрашиваете на созвоне "почему сдвинулся срок?" и слышите "мы уже работаем над этим". Дело не в том, что подрядчик плохой или по какой-то причине пытается саботировать работу, просто сам процесс изначально не предполагал конкретной отчётности, этапов согласования и доступов к беклогу или трекеру. Контроль - это не про то, кто говорит «согласовано» или кого наказать в случае неудачи. Это про то, видите ли вы ход проекта, знаете ли, что конкретно и как делает ваш подрядчик, и кто с вашей стороны может точно сказать, что и где может сломаться до того, как это станет проблемой. Поэтому прежде чем подписывать договор с любым подрядчиком, добейтесь внятных ответов на четыре вопроса: 1. Кто конкретно ведёт архитектуру? 2. Будут ли регулярные демо и с какой частотой? 3. Дадут ли вам доступ к трекеру задач? 4. Как будет выстроена отчётность - не "по запросу", а по графику? Без этих четырёх пунктов контролировать процесс не получится.

Найти нормального подрядчика на разработку было непросто и раньше. Сейчас - сложнее вдвойне. Почти в каждом проекте так или иначе используется AI: где-то Copilot, где-то Cursor, где-то Claude Code, Chat GPT и т.д. И на этом фоне разговор о том, кто реально отвечает за результат, размывается ещё сильнее. А разбираться с тем, как именно написан код, архитектура, как это всё протестировано и т.д. придётся вам. Мы же расписывали зоны ответственности задолго до того, как это стало общей проблемой рынка. На старте проекта всегда понятно, кто ведёт архитектуру, кто отвечает за тестирование, кто отвечает за сроки - и почему именно так, а не иначе. Ещё до старта мы вместе с заказчиком согласовываем отчётность: какая именно, как часто и в каком формате. Это не бюрократия, а способ избежать недопониманий с самого начала. Если вы устали от созвонов, после которых остаётся больше вопросов, чем ответов — приходите, разложим всё по полочкам. 🌐https://ittest.ru/ 🥸 Telegram

Тесты стареют быстрее, чем вы успеваете это заметить📉 Если честно, это довольно неприятное открытие — когда понимаешь, что тест-кейс, который прошёл вчера, проверяет то, чего уже нет. Требование поменяли в трекере полгода назад, никто не заметил, а тест как ни в чём не бывало продолжает зеленеть в отчётах. Мы это видели на многих проектах — и сделали матрицу трассировки требований, чтобы такое больше не всплывало сюрпризом. Что она умеет: - сама подтягивает требования из трекера, руками переносить не нужно - показывает, что покрыто тестами, а что нет - если требование меняется по сути — помечает связанный тест: «Требуется актуализация» - может сразу собрать тест-кейс из контекста требования с помощью ИИ - работает в обе стороны: статус покрытия видно и в DoQA, и в самом трекере Требования при этом никуда не переезжают — остаются там, где жили. Мы не тащим вас в новую систему, просто наводим мост между тем, что уже есть. Почитать подробнее можно у нас на сайте 🌐 https://doqa.app/ 🥸 Telegram 🤩 Мы в MAX

Наш QA Lead Андрей Бракоренко выступил на Summer Merge — антиконференции про айти на берегу Волги 🌊 Формат Summer Merge — не обычный: 3 дня на Русском берегу, доклады, альтернативные активности, концертная программа и явный акцент на work-life balance. Андрей поехал с докладом «Аудит тестирования: как мы лечили QA на финтех-проекте» — про то, как 280 часов аудита превратились в новую модель QA-процессов для клиента, у которого дефекты уходили в прод, несмотря на активно работающую команду тестирования. Спойлер: классические инструменты аудита пришлось выбросить в первые дни — ни требований, ни тест-кейсов не было. Как выкручивались — Андрей рассказал в докладе. Вместе с ним ездил Илья Терехин, наш лид разработки — уже в качестве слушателя. Кстати, если хочется поговорить про аудит QA или тестирование в вашем продукте — Андрей с командой именно этим и занимаются😎 Написать нам: 📧 Почта - office@ittest-team.ru 🥸 Telegram

📊Как мы учим тестировщиков точно оценивать задачи — и где это не работает Наш QA-лид написал на Хабре честный разбор: почему оценки на тестирование почти всегда расходятся с реальностью, и что мы делаем, чтобы расхождение было меньше. В статье — семь конкретных причин ошибок в эстимейтах, с которыми сталкивается любая QA-команда: туман в требованиях, недооценка дефект-циклов, комбинаторные взрывы, когнитивные искажения и другие. По каждой — решение, которое реально применяли на наших проектах. Отдельно — честный вывод: подход сработал не везде. На проектах с прямым менеджментом метрика реально работает. На аутстаффе, где наш специалист — точка экспертной поддержки, а не руководитель команды клиента, встроить системный подход в чужую рутину сложнее. Если работаете с QA-командой и узнаёте свои проблемы в статье — велком в комментарии, обсудим. 👉Читать на Хабре

🆘 Что делать, если компания, которая писала вашу основную бизнес-систему, ушла с рынка — а сама система продолжает крутить весь ваш операционный процесс? Несколько российских сетей коворкингов оказались именно в этой ситуации. Платформа SpacePass — на которой держались онлайн-бронирования, биллинг, СКУД, интеграции с 1С и AmoCRM, личные кабинеты и мобильные приложения резидентов — объявила о прекращении технической поддержки своих клиентов. По нашим оценкам, без сопровождения осталось 15–20 компаний по России. Часть из них мы взяли на поддержку. Не потому что искали такую работу, а потому что уже знали продукт изнутри — на SpacePass работал наш клиент SOK, и мы давно копались в её архитектуре. В статье разобрали: ➡️ как заходить в чужой продукт без передачи дел и документации ➡️ почему такая система не умирает сразу, а деградирует по кусочкам — SSL-сертификаты, налоговые ставки, протоколы платёжек ➡️ как выглядит «поддержка», когда ты не писал систему сам ➡️ почему дешевле звать тех, кто уже погружён, чем учить нового разработчика с нуля 👉 Читать статью

Написали в блог про то, как развернули корпоративный форк Signal — и почему это оказалось совсем не так просто, как звучит Signal — open-source. Казалось бы, берёшь исходники и разворачиваешь у себя. На практике это сложная распределённая система с криптографией, кучей зависимостей и нулём документации по самостоятельному запуску. Мы взялись. Три месяца до первого рабочего запуска, потом два года поддержки и обновлений. Самое интересное случилось в апреле 2025-го: Intel отключил облачную схему аттестации для SGX-компонентов — критической части инфраструктуры. Старая конфигурация перестала работать. Разработчик, который помогал нам при первом запуске, сам не смог разобраться с новой версией. Мы смогли. И запустили новый SGX-сервис примерно в пять раз дешевле базовой конфигурации. В статье рассказали: что именно пришлось делать, какие были сложности и в каких сценариях такое решение вообще оправдано (спойлер — не всегда). 👉 Читать статью

Сегодня нашей компании исполняется 10 лет. Начинали впятером — с идеей и без особых гарантий. Через неделю подписали первый контракт. Дальше — просто работали. От аутсорс-компании по тестированию до полного цикла разработки цифровых продуктов. 200+ проектов, три офиса, клиенты из топ-100 Forbes. Мы всё ещё здесь. И планов — достаточно. Спасибо всем, кто был рядом — клиентам, партнёрам, команде. 🫶

Выложили новый кейс — маркетплейс приложений для роботов VVP Group VVP Group поставляет роботов на базе Nvidia Jetson Orin. Платформа открытая — на неё можно ставить любое ПО. Звучит круто, но на практике оказалось: готового софта под неё на рынке нет, стандартов разработки — тоже. Каждый робот настраивался вручную: инженер, скрипты, несколько часов. Продавать в таком режиме можно, масштабировать — уже нет. Задача была следующая: убрать инженера из процесса установки ПО и сделать так, чтобы робот был готов к работе без погружения в Linux и командную строку. Мы сделали двухуровневую платформу — маркетплейс приложений и корневое ПО на стороне робота, которое связывает устройство с каталогом. Установка в один клик, управление через браузер или смартфон, новый робот готов к работе за 10 минут. Самое интересное в кейсе — как мы принимали архитектурные решения в условиях высокой неопределённости и почему платформа изначально проектировалась без жёсткой привязки к конкретному производителю роботов. Для VVP Group это не просто удобный интерфейс — компания получила собственную программную платформу и другую позицию на рынке. Читайте кейс целиком на сайте — там всё подробно разобрали