Сегодня нашей компании исполняется 10 лет.
Начинали впятером — с идеей и без особых
гарантий. Через неделю подписали первый
контракт. Дальше — просто работали.
От аутсорс-компании по тестированию
до полного цикла разработки цифровых
продуктов. 200+ проектов, три офиса,
клиенты из топ-100 Forbes.
Мы всё ещё здесь. И планов — достаточно.
Спасибо всем, кто был рядом —
клиентам, партнёрам, команде. 🫶
Начинали впятером — с идеей и без особых
гарантий. Через неделю подписали первый
контракт. Дальше — просто работали.
От аутсорс-компании по тестированию
до полного цикла разработки цифровых
продуктов. 200+ проектов, три офиса,
клиенты из топ-100 Forbes.
Мы всё ещё здесь. И планов — достаточно.
Спасибо всем, кто был рядом —
клиентам, партнёрам, команде. 🫶
❤19🔥9🏆2🍾2🌚1
Написали в блог про то, как развернули корпоративный форк Signal — и почему это оказалось совсем не так просто, как звучит
Signal — open-source. Казалось бы, берёшь исходники и разворачиваешь у себя. На практике это сложная распределённая система с криптографией, кучей зависимостей и нулём документации по самостоятельному запуску.
Мы взялись. Три месяца до первого рабочего запуска, потом два года поддержки и обновлений.
Самое интересное случилось в апреле 2025-го: Intel отключил облачную схему аттестации для SGX-компонентов — критической части инфраструктуры. Старая конфигурация перестала работать. Разработчик, который помогал нам при первом запуске, сам не смог разобраться с новой версией. Мы смогли. И запустили новый SGX-сервис примерно в пять раз дешевле базовой конфигурации.
В статье рассказали: что именно пришлось делать, какие были сложности и в каких сценариях такое решение вообще оправдано (спойлер — не всегда).
👉 Читать статью
Signal — open-source. Казалось бы, берёшь исходники и разворачиваешь у себя. На практике это сложная распределённая система с криптографией, кучей зависимостей и нулём документации по самостоятельному запуску.
Мы взялись. Три месяца до первого рабочего запуска, потом два года поддержки и обновлений.
Самое интересное случилось в апреле 2025-го: Intel отключил облачную схему аттестации для SGX-компонентов — критической части инфраструктуры. Старая конфигурация перестала работать. Разработчик, который помогал нам при первом запуске, сам не смог разобраться с новой версией. Мы смогли. И запустили новый SGX-сервис примерно в пять раз дешевле базовой конфигурации.
В статье рассказали: что именно пришлось делать, какие были сложности и в каких сценариях такое решение вообще оправдано (спойлер — не всегда).
👉 Читать статью
🔥9👏6
🆘 Что делать, если компания, которая писала вашу основную бизнес-систему, ушла с рынка — а сама система продолжает крутить весь ваш операционный процесс?
Несколько российских сетей коворкингов оказались именно в этой ситуации. Платформа SpacePass — на которой держались онлайн-бронирования, биллинг, СКУД, интеграции с 1С и AmoCRM, личные кабинеты и мобильные приложения резидентов — объявила о прекращении технической поддержки своих клиентов. По нашим оценкам, без сопровождения осталось 15–20 компаний по России.
Часть из них мы взяли на поддержку. Не потому что искали такую работу, а потому что уже знали продукт изнутри — на SpacePass работал наш клиент SOK, и мы давно копались в её архитектуре.
В статье разобрали:
➡️ как заходить в чужой продукт без передачи дел и документации
➡️ почему такая система не умирает сразу, а деградирует по кусочкам — SSL-сертификаты, налоговые ставки, протоколы платёжек
➡️ как выглядит «поддержка», когда ты не писал систему сам
➡️ почему дешевле звать тех, кто уже погружён, чем учить нового разработчика с нуля
👉 Читать статью
Несколько российских сетей коворкингов оказались именно в этой ситуации. Платформа SpacePass — на которой держались онлайн-бронирования, биллинг, СКУД, интеграции с 1С и AmoCRM, личные кабинеты и мобильные приложения резидентов — объявила о прекращении технической поддержки своих клиентов. По нашим оценкам, без сопровождения осталось 15–20 компаний по России.
Часть из них мы взяли на поддержку. Не потому что искали такую работу, а потому что уже знали продукт изнутри — на SpacePass работал наш клиент SOK, и мы давно копались в её архитектуре.
В статье разобрали:
➡️ как заходить в чужой продукт без передачи дел и документации
➡️ почему такая система не умирает сразу, а деградирует по кусочкам — SSL-сертификаты, налоговые ставки, протоколы платёжек
➡️ как выглядит «поддержка», когда ты не писал систему сам
➡️ почему дешевле звать тех, кто уже погружён, чем учить нового разработчика с нуля
👉 Читать статью
🔥5👏4❤3
📊Как мы учим тестировщиков точно оценивать задачи — и где это не работает
Наш QA-лид написал на Хабре честный разбор: почему оценки на тестирование почти всегда расходятся с реальностью, и что мы делаем, чтобы расхождение было меньше.
В статье — семь конкретных причин ошибок в эстимейтах, с которыми сталкивается любая QA-команда: туман в требованиях, недооценка дефект-циклов, комбинаторные взрывы, когнитивные искажения и другие. По каждой — решение, которое реально применяли на наших проектах.
Отдельно — честный вывод: подход сработал не везде. На проектах с прямым менеджментом метрика реально работает. На аутстаффе, где наш специалист — точка экспертной поддержки, а не руководитель команды клиента, встроить системный подход в чужую рутину сложнее.
Если работаете с QA-командой и узнаёте свои проблемы в статье — велком в комментарии, обсудим.
👉Читать на Хабре
Наш QA-лид написал на Хабре честный разбор: почему оценки на тестирование почти всегда расходятся с реальностью, и что мы делаем, чтобы расхождение было меньше.
В статье — семь конкретных причин ошибок в эстимейтах, с которыми сталкивается любая QA-команда: туман в требованиях, недооценка дефект-циклов, комбинаторные взрывы, когнитивные искажения и другие. По каждой — решение, которое реально применяли на наших проектах.
Отдельно — честный вывод: подход сработал не везде. На проектах с прямым менеджментом метрика реально работает. На аутстаффе, где наш специалист — точка экспертной поддержки, а не руководитель команды клиента, встроить системный подход в чужую рутину сложнее.
Если работаете с QA-командой и узнаёте свои проблемы в статье — велком в комментарии, обсудим.
👉Читать на Хабре
🔥6❤2
Наш QA Lead Андрей Бракоренко выступил на Summer Merge — антиконференции про айти на берегу Волги 🌊
Формат Summer Merge — не обычный: 3 дня на Русском берегу, доклады, альтернативные активности, концертная программа и явный акцент на work-life balance. Андрей поехал с докладом «Аудит тестирования: как мы лечили QA на финтех-проекте» — про то, как 280 часов аудита превратились в новую модель QA-процессов для клиента, у которого дефекты уходили в прод, несмотря на активно работающую команду тестирования.
Спойлер: классические инструменты аудита пришлось выбросить в первые дни — ни требований, ни тест-кейсов не было. Как выкручивались — Андрей рассказал в докладе.
Вместе с ним ездил Илья Терехин, наш лид разработки — уже в качестве слушателя.
Кстати, если хочется поговорить про аудит QA или тестирование в вашем продукте — Андрей с командой именно этим и занимаются😎
Написать нам:
📧 Почта - office@ittest-team.ru
🥸 Telegram
Формат Summer Merge — не обычный: 3 дня на Русском берегу, доклады, альтернативные активности, концертная программа и явный акцент на work-life balance. Андрей поехал с докладом «Аудит тестирования: как мы лечили QA на финтех-проекте» — про то, как 280 часов аудита превратились в новую модель QA-процессов для клиента, у которого дефекты уходили в прод, несмотря на активно работающую команду тестирования.
Спойлер: классические инструменты аудита пришлось выбросить в первые дни — ни требований, ни тест-кейсов не было. Как выкручивались — Андрей рассказал в докладе.
Вместе с ним ездил Илья Терехин, наш лид разработки — уже в качестве слушателя.
Кстати, если хочется поговорить про аудит QA или тестирование в вашем продукте — Андрей с командой именно этим и занимаются😎
Написать нам:
📧 Почта - office@ittest-team.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13⚡5
Forwarded from DoQA
Тесты стареют быстрее, чем вы успеваете это заметить📉
Если честно, это довольно неприятное открытие — когда понимаешь, что тест-кейс, который прошёл вчера, проверяет то, чего уже нет.
Требование поменяли в трекере полгода назад, никто не заметил, а тест как ни в чём не бывало продолжает зеленеть в отчётах.
Мы это видели на многих проектах — и сделали матрицу трассировки требований, чтобы такое больше не всплывало сюрпризом.
Что она умеет:
- сама подтягивает требования из трекера, руками переносить не нужно
- показывает, что покрыто тестами, а что нет
- если требование меняется по сути — помечает связанный тест: «Требуется актуализация»
- может сразу собрать тест-кейс из контекста требования с помощью ИИ
- работает в обе стороны: статус покрытия видно и в DoQA, и в самом трекере
Требования при этом никуда не переезжают — остаются там, где жили. Мы не тащим вас в новую систему, просто наводим мост между тем, что уже есть.
Почитать подробнее можно у нас на сайте
🌐 https://doqa.app/
🥸 Telegram
🤩 Мы в MAX
Если честно, это довольно неприятное открытие — когда понимаешь, что тест-кейс, который прошёл вчера, проверяет то, чего уже нет.
Требование поменяли в трекере полгода назад, никто не заметил, а тест как ни в чём не бывало продолжает зеленеть в отчётах.
Мы это видели на многих проектах — и сделали матрицу трассировки требований, чтобы такое больше не всплывало сюрпризом.
Что она умеет:
- сама подтягивает требования из трекера, руками переносить не нужно
- показывает, что покрыто тестами, а что нет
- если требование меняется по сути — помечает связанный тест: «Требуется актуализация»
- может сразу собрать тест-кейс из контекста требования с помощью ИИ
- работает в обе стороны: статус покрытия видно и в DoQA, и в самом трекере
Требования при этом никуда не переезжают — остаются там, где жили. Мы не тащим вас в новую систему, просто наводим мост между тем, что уже есть.
Почитать подробнее можно у нас на сайте
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4😁1
Найти нормального подрядчика на разработку было непросто и раньше. Сейчас - сложнее вдвойне.
Почти в каждом проекте так или иначе используется AI: где-то Copilot, где-то Cursor, где-то Claude Code, Chat GPT и т.д. И на этом фоне разговор о том, кто реально отвечает за результат, размывается ещё сильнее. А разбираться с тем, как именно написан код, архитектура, как это всё протестировано и т.д. придётся вам.
Мы же расписывали зоны ответственности задолго до того, как это стало общей проблемой рынка. На старте проекта всегда понятно, кто ведёт архитектуру, кто отвечает за тестирование, кто отвечает за сроки - и почему именно так, а не иначе.
Ещё до старта мы вместе с заказчиком согласовываем отчётность: какая именно, как часто и в каком формате. Это не бюрократия, а способ избежать недопониманий с самого начала.
Если вы устали от созвонов, после которых остаётся больше вопросов, чем ответов — приходите, разложим всё по полочкам.
🌐https://ittest.ru/
🥸 Telegram
Почти в каждом проекте так или иначе используется AI: где-то Copilot, где-то Cursor, где-то Claude Code, Chat GPT и т.д. И на этом фоне разговор о том, кто реально отвечает за результат, размывается ещё сильнее. А разбираться с тем, как именно написан код, архитектура, как это всё протестировано и т.д. придётся вам.
Мы же расписывали зоны ответственности задолго до того, как это стало общей проблемой рынка. На старте проекта всегда понятно, кто ведёт архитектуру, кто отвечает за тестирование, кто отвечает за сроки - и почему именно так, а не иначе.
Ещё до старта мы вместе с заказчиком согласовываем отчётность: какая именно, как часто и в каком формате. Это не бюрократия, а способ избежать недопониманий с самого начала.
Если вы устали от созвонов, после которых остаётся больше вопросов, чем ответов — приходите, разложим всё по полочкам.
🌐https://ittest.ru/
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5⚡3🤣2
"Отдать разработку на аутсорс - значит потерять контроль над проектом". Один из самых живучих мифов у заказчиков.
На практике контроль теряют не из-за формата работы, а из-за того, как он выстроен:
• нет регулярных демо и статус-встреч, поэтому о состоянии проекта вы узнаёте по факту, а не заранее;
• нет доступа к беклогу и трекеру задач, поэтому непонятно, что вообще происходит между созвонами;
• архитектурные решения принимаются без согласования, и вы узнаёте узнаёт о них, когда переделывать уже поздно;
• отчётность даётся «по запросу», а не по согласованному графику, поэтому спрашивать приходится самому.
Знакомая ситуация: спрашиваете на созвоне "почему сдвинулся срок?" и слышите "мы уже работаем над этим".
Дело не в том, что подрядчик плохой или по какой-то причине пытается саботировать работу, просто сам процесс изначально не предполагал конкретной отчётности, этапов согласования и доступов к беклогу или трекеру.
Контроль - это не про то, кто говорит «согласовано» или кого наказать в случае неудачи.
Это про то, видите ли вы ход проекта, знаете ли, что конкретно и как делает ваш подрядчик, и кто с вашей стороны может точно сказать, что и где может сломаться до того, как это станет проблемой.
Поэтому прежде чем подписывать договор с любым подрядчиком, добейтесь внятных ответов на четыре вопроса:
1. Кто конкретно ведёт архитектуру?
2. Будут ли регулярные демо и с какой частотой?
3. Дадут ли вам доступ к трекеру задач?
4. Как будет выстроена отчётность - не "по запросу", а по графику?
Без этих четырёх пунктов контролировать процесс не получится.
На практике контроль теряют не из-за формата работы, а из-за того, как он выстроен:
• нет регулярных демо и статус-встреч, поэтому о состоянии проекта вы узнаёте по факту, а не заранее;
• нет доступа к беклогу и трекеру задач, поэтому непонятно, что вообще происходит между созвонами;
• архитектурные решения принимаются без согласования, и вы узнаёте узнаёт о них, когда переделывать уже поздно;
• отчётность даётся «по запросу», а не по согласованному графику, поэтому спрашивать приходится самому.
Знакомая ситуация: спрашиваете на созвоне "почему сдвинулся срок?" и слышите "мы уже работаем над этим".
Дело не в том, что подрядчик плохой или по какой-то причине пытается саботировать работу, просто сам процесс изначально не предполагал конкретной отчётности, этапов согласования и доступов к беклогу или трекеру.
Контроль - это не про то, кто говорит «согласовано» или кого наказать в случае неудачи.
Это про то, видите ли вы ход проекта, знаете ли, что конкретно и как делает ваш подрядчик, и кто с вашей стороны может точно сказать, что и где может сломаться до того, как это станет проблемой.
Поэтому прежде чем подписывать договор с любым подрядчиком, добейтесь внятных ответов на четыре вопроса:
1. Кто конкретно ведёт архитектуру?
2. Будут ли регулярные демо и с какой частотой?
3. Дадут ли вам доступ к трекеру задач?
4. Как будет выстроена отчётность - не "по запросу", а по графику?
Без этих четырёх пунктов контролировать процесс не получится.
🔥7❤5🏆2
Тестирование было нашей ключевой экспертизой ещё до того, как мы начали разрабатывать сайты и мобильные приложения. Мы занимаемся этим достаточно давно, чтобы знать: тестировщикам не нужен ещё один красивый интерфейс - им нужно, чтобы рутина не съедала время и инструмент действительно помогал в работе.
Именно это мы заложили в DoQA.
Например, заголовок баг-репорта тестировщик обычно пишет на бегу, просто описывая, что получилось. DoQA сама формирует чёткий заголовок по описанию фактического результата - мелочь, но таких мелочей за день набирается на десятки багов.
Или другая рутина: перечитывать свои же тест-кейсы на полноту и ясность формулировок. DoQA проверяет кейс на атомарность и на ясность цели. Если что-то не так, сразу предлагает правки которые можно применить одной кнопкой.
Ещё одна вечная головная боль QA-лида - доказать, что команда протестировала именно то, что должна была, а не просто накопила гору тест-кейсов. Требования живут в трекере, тесты - в TMS, и без ручной сверки понять реальное покрытие почти невозможно.
В DoQA есть матрица трассировки: она напрямую связывает требования из Jira с тест-кейсами и результатами прогонов, показывает, что осталось непокрытым, а если требование поменялось - помечает связанные тесты статусом «требуется актуализация», чтобы старый результат не вводил в заблуждение.
Документация и подробности на сайте doqa.app
Именно это мы заложили в DoQA.
Например, заголовок баг-репорта тестировщик обычно пишет на бегу, просто описывая, что получилось. DoQA сама формирует чёткий заголовок по описанию фактического результата - мелочь, но таких мелочей за день набирается на десятки багов.
Или другая рутина: перечитывать свои же тест-кейсы на полноту и ясность формулировок. DoQA проверяет кейс на атомарность и на ясность цели. Если что-то не так, сразу предлагает правки которые можно применить одной кнопкой.
Ещё одна вечная головная боль QA-лида - доказать, что команда протестировала именно то, что должна была, а не просто накопила гору тест-кейсов. Требования живут в трекере, тесты - в TMS, и без ручной сверки понять реальное покрытие почти невозможно.
В DoQA есть матрица трассировки: она напрямую связывает требования из Jira с тест-кейсами и результатами прогонов, показывает, что осталось непокрытым, а если требование поменялось - помечает связанные тесты статусом «требуется актуализация», чтобы старый результат не вводил в заблуждение.
Документация и подробности на сайте doqa.app
⚡4🔥1
«Рынок IT не умер, но лёгкой жизни на нём больше нет» — так наш HR подытожила, что происходит на рынке труда в QA и разработке этой осенью.
Цифры подтверждают: в первом полугодии 2026 IT-вакансий стало на 21% меньше, чем годом раньше, а резюме — наоборот, на 21% больше. Рынок развернулся: раньше компании конкурировали за специалистов, теперь специалистам приходится конкурировать между собой.
Сильнее всего это ударило по простым позициям. Junior Manual QA без технической базы — таких кандидатов сейчас очень много, а вакансий под них мало. Похожая история у части junior-разработчиков: курсы они прошли, а реального опыта с production-кодом, Git, базами и API нет.
При этом легче не стало и senior-специалистам. Вакансий тоже меньше, а требования конкретнее: не «Senior QA», а «QA с API, SQL, автоматизацией и CI/CD». Рынок стал покупать не стаж, а доказанную экспертизу и человек с 8–10 годами опыта вполне может искать подходящую позицию месяцами.
Главный сдвиг: AI не сужает требования к специалистам, а расширяет их. От QA всё чаще ждут не только ручного тестирования, но и API, SQL, автотестов, Git, CI/CD, работы с логами. Сильная связка сейчас — QA + API + SQL + Git + автоматизация, ещё сильнее — AQA/SDET.
Резкого разворота осенью не будет — компании продолжат нанимать точечно, под конкретный набор навыков, а не «ещё одного QA».
Мы в IT Test как раз ищем таких людей — открытые позиции: ittest.ru/career
Цифры подтверждают: в первом полугодии 2026 IT-вакансий стало на 21% меньше, чем годом раньше, а резюме — наоборот, на 21% больше. Рынок развернулся: раньше компании конкурировали за специалистов, теперь специалистам приходится конкурировать между собой.
Сильнее всего это ударило по простым позициям. Junior Manual QA без технической базы — таких кандидатов сейчас очень много, а вакансий под них мало. Похожая история у части junior-разработчиков: курсы они прошли, а реального опыта с production-кодом, Git, базами и API нет.
При этом легче не стало и senior-специалистам. Вакансий тоже меньше, а требования конкретнее: не «Senior QA», а «QA с API, SQL, автоматизацией и CI/CD». Рынок стал покупать не стаж, а доказанную экспертизу и человек с 8–10 годами опыта вполне может искать подходящую позицию месяцами.
Главный сдвиг: AI не сужает требования к специалистам, а расширяет их. От QA всё чаще ждут не только ручного тестирования, но и API, SQL, автотестов, Git, CI/CD, работы с логами. Сильная связка сейчас — QA + API + SQL + Git + автоматизация, ещё сильнее — AQA/SDET.
Резкого разворота осенью не будет — компании продолжат нанимать точечно, под конкретный набор навыков, а не «ещё одного QA».
Мы в IT Test как раз ищем таких людей — открытые позиции: ittest.ru/career
🔥4
Сроки сдвигаются, а причина каждый раз новая и неожиданная🧐
"Не учли сложность интеграции..."
"Заболел ключевой разработчик..."
"Оказалось сложнее, чем думали..."
По отдельности все эти причины - обыденность разработки, но если посторяется 3-4 раза подряд - уже закономерность.
Собрали чек-лист из своей практики - те звоночки, с которыми к нам чаще всего приходили заказчики, когда искали новую команду:
• сроки плавают без внятного объяснения
• отчётность приходится выпрашивать
• никто не может сказать, кто конкретно делает задачу
• архитектурные решения принимаются без вас
• тестирование - по остаточному принципу
• "всё под контролем", "мы уже разбираемся" и другие типовые ответы на прямые вопросы
И отдельно - что делать до того, как расторгать договор: как зафиксировать факты, о чём спросить прямо и когда стоит заказать независимый аудит.
Читайте в нашей новой статье → https://clck.ru/3VGocN
"Не учли сложность интеграции..."
"Заболел ключевой разработчик..."
"Оказалось сложнее, чем думали..."
По отдельности все эти причины - обыденность разработки, но если посторяется 3-4 раза подряд - уже закономерность.
Собрали чек-лист из своей практики - те звоночки, с которыми к нам чаще всего приходили заказчики, когда искали новую команду:
• сроки плавают без внятного объяснения
• отчётность приходится выпрашивать
• никто не может сказать, кто конкретно делает задачу
• архитектурные решения принимаются без вас
• тестирование - по остаточному принципу
• "всё под контролем", "мы уже разбираемся" и другие типовые ответы на прямые вопросы
И отдельно - что делать до того, как расторгать договор: как зафиксировать факты, о чём спросить прямо и когда стоит заказать независимый аудит.
Читайте в нашей новой статье → https://clck.ru/3VGocN
👍5⚡3
Рынок тестирования в России в 2026-м раскололся на два лагеря: "чистый" Manual QA и гибридный SDET - тестировщик, который пишет автотесты и код наравне с разработчиком.
Разница между ними в трёх вещах:
• переход в автоматизацию
• знание языка программирования
• опыт в продуктовой или финтех-разработке.
Ручной тестировщик без этих навыков упирается в потолок карьерного роста раньше остальных. Компании всё чаще ищут не "ручника", а инженера, способного закрыть и функциональное, и автоматизированное тестирование.
Если вы уже в QA или только заходите в профессию, то вот три ориентира в 2026:
✅ автоматизация - не доп., а проходка в Middle+;
✅ один язык программирования (Python, Java, JS) закрывает 70% вакансий SDET;
✅ опыт в продукте или финтехе повышает ценность специалиста больше, чем ещё один сертификат.
Разница между ними в трёх вещах:
• переход в автоматизацию
• знание языка программирования
• опыт в продуктовой или финтех-разработке.
Ручной тестировщик без этих навыков упирается в потолок карьерного роста раньше остальных. Компании всё чаще ищут не "ручника", а инженера, способного закрыть и функциональное, и автоматизированное тестирование.
Если вы уже в QA или только заходите в профессию, то вот три ориентира в 2026:
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡6
С 2026 года в реестр российского ПО попадают только продукты, прошедшие проверку на соответствие требованиям ФСБ и ФСТЭК. При этом около трети крупного бизнеса в России до сих пор работает на закупленном раньше иностранном софте.
Для компаний, которые переходят на отечественный стек, это не уже не простая формальность. Проверка на ИБ - отдельный этап, который нужно закладывать в план перехода отдельной строкой. Практика 2026 года окончательно ушла от сценария "срочно заменить" к управляемому технологическому переходу с обязательным тестированием безопасности на каждом шаге.
Если вы планируете переход на отечественное ПО, вот три пункта, которые обязательно нужно проверить на старте:
1) соответствует ли выбранное решение актуальным требованиям ФСТЭК(с 2023–2024 года они поменялись);
2) заложено ли отдельное время на тестирование ИБ;
3) есть ли в команде, которая ведёт переезд, экспертиза именно в проверке безопасности.
Для компаний, которые переходят на отечественный стек, это не уже не простая формальность. Проверка на ИБ - отдельный этап, который нужно закладывать в план перехода отдельной строкой. Практика 2026 года окончательно ушла от сценария "срочно заменить" к управляемому технологическому переходу с обязательным тестированием безопасности на каждом шаге.
Если вы планируете переход на отечественное ПО, вот три пункта, которые обязательно нужно проверить на старте:
1) соответствует ли выбранное решение актуальным требованиям ФСТЭК(с 2023–2024 года они поменялись);
2) заложено ли отдельное время на тестирование ИБ;
3) есть ли в команде, которая ведёт переезд, экспертиза именно в проверке безопасности.
⚡8
У большинства TMS в России пока нет выбора модели для ИИ-функций. В DoQA с релиза 4.2 мы это пофиксили: помимо OpenAI и YandexGPT, можно подключить GigaChat, DeepSeek или локальную модель через Ollama. Т.е. держать весь ИИ-контур внутри своего периметра, без данных, уходящих во внешний сервис.
Это отвечает на конкретный запрос enterprise-заказчиков с жёсткими требованиями ИБ: тест-кейсы и требования часто содержат чувствительные данные о продукте, и не каждая компания готова прогонять их через облачный LLM.
Вместе с этим в DoQA уже работает массовая генерация тест-кейсов и связка "клик по требованию → готовый набор тест-кейсов, автоматически привязанный к этому требованию" - рутина, которая раньше отнимала часы теперь занимает пару секунд.🤖
Важно понимать, что ИИ не заменит тестировщика(по крайней мере на текущем уровне развития), а в освободившееся время QA может заняться тем, чего ИИ пока не умеет - приоритизацией рисков и глубоким погружением в продукт.
Это отвечает на конкретный запрос enterprise-заказчиков с жёсткими требованиями ИБ: тест-кейсы и требования часто содержат чувствительные данные о продукте, и не каждая компания готова прогонять их через облачный LLM.
Вместе с этим в DoQA уже работает массовая генерация тест-кейсов и связка "клик по требованию → готовый набор тест-кейсов, автоматически привязанный к этому требованию" - рутина, которая раньше отнимала часы теперь занимает пару секунд.🤖
Важно понимать, что ИИ не заменит тестировщика(по крайней мере на текущем уровне развития), а в освободившееся время QA может заняться тем, чего ИИ пока не умеет - приоритизацией рисков и глубоким погружением в продукт.
⚡6
На HeadHunter сейчас открыто больше 3000 вакансий в тестировании. При этом на одну позицию без опыта приходят сотни откликов - вход в профессию сузился заметно сильнее, чем сам рынок вакансий в целом.
Такой разрыв очень просто объясняется - компании готовы платить за навыки анализа и автоматизации, а не за факт прохождения курсов. Тестировщик, который умеет писать автотесты, работать с CI/CD и разбираться в логах с помощью ИИ-инструментов ценится гораздо выше, чем manual QA без набора выше.
Для тех, кто выбирает между массовым набором джунов и точечным усилением опытными специалистами - вопрос не в дефиците людей на входе, а в дефиците тех, кто готов закрывать сложные задачи с первого дня.
Такой разрыв очень просто объясняется - компании готовы платить за навыки анализа и автоматизации, а не за факт прохождения курсов. Тестировщик, который умеет писать автотесты, работать с CI/CD и разбираться в логах с помощью ИИ-инструментов ценится гораздо выше, чем manual QA без набора выше.
Для тех, кто выбирает между массовым набором джунов и точечным усилением опытными специалистами - вопрос не в дефиците людей на входе, а в дефиците тех, кто готов закрывать сложные задачи с первого дня.
👍4🏆2
К нам периодически приходят "за аутсорсом", а после разговора и погружения в задачу выясняется, что нужен аутстафф. И наоборот. В последнее время такая ситуация происходит настолько часто, что мы решили написать короткую статью на эту тему.
Разница между форматами не в цене и не в том, удалённо работают люди или нет. Разница в том, кто управляет процессом и кто отвечает за результат.
Аутстафф работает, если у вас уже есть свои процессы и тех.лид, способный рулить внешними специалистами как своими.
Аутсорс - если экспертизы или мощностей на управление просто нет, и вы готовы отдать подрядчику "как", оставив себе только "что" и "зачем".
Мы работаем в обеих моделях и не продаём одну и ту же под любую задачу. Сначала разбираемся готовы ли вы сами управлять процессом, и уже потом, исходя из ваших ответов, предлагаем определённый формат.
В статье - чек-лист из 5 вопросов, которые стоит задать себе и любому подрядчику до подписания договора (не только нам). Один из пунктов: если в ответ слышите "команда профессионалов" и "индивидуальный подход" вместо конкретных ответов на ваши вопросы - это повод насторожиться. 👀
Читать статью: ittest.ru/blog/autsors-ili-autstaff-kak-vybrat
Разница между форматами не в цене и не в том, удалённо работают люди или нет. Разница в том, кто управляет процессом и кто отвечает за результат.
Аутстафф работает, если у вас уже есть свои процессы и тех.лид, способный рулить внешними специалистами как своими.
Аутсорс - если экспертизы или мощностей на управление просто нет, и вы готовы отдать подрядчику "как", оставив себе только "что" и "зачем".
Мы работаем в обеих моделях и не продаём одну и ту же под любую задачу. Сначала разбираемся готовы ли вы сами управлять процессом, и уже потом, исходя из ваших ответов, предлагаем определённый формат.
В статье - чек-лист из 5 вопросов, которые стоит задать себе и любому подрядчику до подписания договора (не только нам). Один из пунктов: если в ответ слышите "команда профессионалов" и "индивидуальный подход" вместо конкретных ответов на ваши вопросы - это повод насторожиться. 👀
Читать статью: ittest.ru/blog/autsors-ili-autstaff-kak-vybrat
❤2🔥2