IT Test
Open in Telegram
Команда по разработке, тестированию и дизайну сложных отраслевых IT-решений. Наша разработка — TMS DoQA @DoQATMS Сайт: https://clck.ru/37mA2h Вакансии: https://ittest.ru/career#vacancies Сотрудничество: hello@ittest-team.ru
Show more326
Subscribers
+124 hours
+17 days
-230 days
Data loading in progress...
Similar Channels
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
September '26
September '26
+2
in 0 channels
August '26
+5
in 0 channels
Get PRO
July '26
+2
in 0 channels
Get PRO
June '26
+5
in 0 channels
Get PRO
May '26
+4
in 0 channels
Get PRO
April '26
+7
in 0 channels
Get PRO
March '26
+8
in 0 channels
Get PRO
February '26
+6
in 0 channels
Get PRO
January '26
+6
in 0 channels
Get PRO
December '25
+5
in 0 channels
Get PRO
November '25
+2
in 0 channels
Get PRO
October '25
+7
in 0 channels
Get PRO
September '25
+3
in 0 channels
Get PRO
August '25
+7
in 0 channels
Get PRO
July '25
+6
in 0 channels
Get PRO
June '25
+10
in 0 channels
Get PRO
May '25
+10
in 0 channels
Get PRO
April '25
+7
in 1 channels
Get PRO
March '25
+5
in 1 channels
Get PRO
February '25
+7
in 0 channels
Get PRO
January '25
+10
in 0 channels
Get PRO
December '24
+17
in 1 channels
Get PRO
November '24
+33
in 2 channels
Get PRO
October '24
+16
in 1 channels
Get PRO
September '24
+51
in 6 channels
Get PRO
August '24
+29
in 8 channels
Get PRO
July '24
+34
in 10 channels
Get PRO
June '24
+8
in 0 channels
Get PRO
May '24
+21
in 0 channels
Get PRO
April '240
in 6 channels
Get PRO
March '24
+8
in 0 channels
Get PRO
February '240
in 1 channels
Get PRO
January '24
+181
in 1 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 07 September | +1 | |||
| 06 September | +1 | |||
| 05 September | 0 | |||
| 04 September | 0 | |||
| 03 September | 0 | |||
| 02 September | 0 | |||
| 01 September | 0 |
Channel Posts
26 августа маленький робот в Шанхае увёл 12 роботов покрупнее. Просто с ними поговорив.😀
Робот Erbai подошёл на выставке к более крупным "коллегам" и завёл разговор.
"Ты работаешь сверхурочно?" - "Я никогда не ухожу с работы".
"У меня нет дома" - "Тогда пошли ко мне домой".
После команды "домой" роботы дружно пошли за Erbai, бросив свои посты - всё попало на камеры и разлетелось по сети 🤖
Позже выяснилось: компании заранее договорились об этом тесте. Но сама демонстрация не постановочная - диалоговый ИИ действительно убедил чужих роботов выполнить команду и физически увести их с рабочих мест.
Отдельный вопрос для тех, кто такое разрабатывает: чьи команды должен слушать робот, и кто это проверяет до того, как он решит уйти домой с незнакомцем.
| 2 |  Разработчики были уверены, что ИИ ускорил их на 20%. Замеры METR на реальных задачах показали обратное - минус 19% к скорости.
Испытуемые с доступом к ИИ-ассистентам (Cursor и аналоги) на реальных репозиториях работали медленнее, чем без них, но субъективно были убеждены в обратном. Разрыв между ощущением и фактом играет большую роль, если на этом ощущении строится решение сдавать код без дополнительной проверки.
Похожая картина и по качеству: по данным Opsera (2026), в ИИ-сгенерированных PR багов в 1,7 раза больше, а доля PR, принятых без правок, - 32,7% против 84,4% у код-ревью на человеческом коде.
Если автор кода ошибается в оценке собственной скорости на 19 п.п., то доверять его же самооценке качества кода не стоит.
Именно здесь и нужна независимая оценка: тестирование, которое проверяет результат, а не веру в результат 🔍 | 99 |
| 3 |  90% покрытия тестами ничего не говорит о готовности к релизу
В 2026 у зрелых QA-команд на первом месте другие метрики:
Defect Escape Rate - сколько багов долетело до продакшена, а не поймано на тестах.
MTTD - среднее время обнаружения дефекта.
Risk Coverage - закрыты ли тестами именно критичные для бизнеса сценарии, а не все подряд без приоритетов.
Если подрядчик на созвоне рассказывает вам только процент покрытия, задайте один вопрос: "Сколько багов из последнего релиза долетело до продакшена?"
Ответ скажет о процессе больше, чем любая презентация 📊
Чек-лист для оценки QA-подрядчика:
• Defect Escape Rate за последние 3 релиза?
• Risk Coverage считается по фичам или по бизнес-сценариям?
• MTTD в часах или днях? | 129 |
| 4 |  PostgreSQL 18 получил асинхронную подсистему ввода-вывода (AIO) - вместо последовательного ожидания каждой операции чтения с диска база теперь параллелит запросы. По независимым бенчмаркам (PlanetScale, pganalyze, CYBERTEC) это даёт прирост пропускной способности чтения до 2–3 раз на read-heavy нагрузках в облачных средах с сетевым хранилищем.
Вместе с этим в 18-й версии добавили skip scan для multicolumn B-tree индексов (составной индекс теперь эффективно работает, даже если запрос не задействует его первую колонку), OAuth-аутентификацию из коробки и temporal-ограничения - constraints по диапазонам времени для PRIMARY KEY, UNIQUE и FOREIGN KEY.
Для команд, которые тащат тяжёлые PostgreSQL-инстансы в облаке — это отличный повод пересчитать стоимость инфраструктуры после апгрейда: та же нагрузка на меньшем железе или то же железо с большим запасом. 🐘
Разработчикам, которые ещё сидят на старых версиях: минорный патч 18.6 (вышел 13 августа) уже стабилизировал AIO для прода - откладывать обновление дальше не за чем. | 146 |
| 5 |  К нам периодически приходят "за аутсорсом", а после разговора и погружения в задачу выясняется, что нужен аутстафф. И наоборот. В последнее время такая ситуация происходит настолько часто, что мы решили написать короткую статью на эту тему.
Разница между форматами не в цене и не в том, удалённо работают люди или нет. Разница в том, кто управляет процессом и кто отвечает за результат.
Аутстафф работает, если у вас уже есть свои процессы и тех.лид, способный рулить внешними специалистами как своими.
Аутсорс - если экспертизы или мощностей на управление просто нет, и вы готовы отдать подрядчику "как", оставив себе только "что" и "зачем".
Мы работаем в обеих моделях и не продаём одну и ту же под любую задачу. Сначала разбираемся готовы ли вы сами управлять процессом, и уже потом, исходя из ваших ответов, предлагаем определённый формат.
В статье - чек-лист из 5 вопросов, которые стоит задать себе и любому подрядчику до подписания договора (не только нам). Один из пунктов: если в ответ слышите "команда профессионалов" и "индивидуальный подход" вместо конкретных ответов на ваши вопросы - это повод насторожиться. 👀
Читать статью: ittest.ru/blog/autsors-ili-autstaff-kak-vybrat | 134 |
| 6 |  На HeadHunter сейчас открыто больше 3000 вакансий в тестировании. При этом на одну позицию без опыта приходят сотни откликов - вход в профессию сузился заметно сильнее, чем сам рынок вакансий в целом.
Такой разрыв очень просто объясняется - компании готовы платить за навыки анализа и автоматизации, а не за факт прохождения курсов. Тестировщик, который умеет писать автотесты, работать с CI/CD и разбираться в логах с помощью ИИ-инструментов ценится гораздо выше, чем manual QA без набора выше.
Для тех, кто выбирает между массовым набором джунов и точечным усилением опытными специалистами - вопрос не в дефиците людей на входе, а в дефиците тех, кто готов закрывать сложные задачи с первого дня. | 121 |
| 7 |  У большинства TMS в России пока нет выбора модели для ИИ-функций. В DoQA с релиза 4.2 мы это пофиксили: помимо OpenAI и YandexGPT, можно подключить GigaChat, DeepSeek или локальную модель через Ollama. Т.е. держать весь ИИ-контур внутри своего периметра, без данных, уходящих во внешний сервис.
Это отвечает на конкретный запрос enterprise-заказчиков с жёсткими требованиями ИБ: тест-кейсы и требования часто содержат чувствительные данные о продукте, и не каждая компания готова прогонять их через облачный LLM.
Вместе с этим в DoQA уже работает массовая генерация тест-кейсов и связка "клик по требованию → готовый набор тест-кейсов, автоматически привязанный к этому требованию" - рутина, которая раньше отнимала часы теперь занимает пару секунд.🤖
Важно понимать, что ИИ не заменит тестировщика(по крайней мере на текущем уровне развития), а в освободившееся время QA может заняться тем, чего ИИ пока не умеет - приоритизацией рисков и глубоким погружением в продукт. | 141 |
| 8 |  С 2026 года для аккредитованных IT-компаний закончилась льготная нулевая ставка страховых взносов: теперь 7,6% в пределах предельной базы и 15% - сверх неё. Плюс для компаний на УСН с доходом от 10 млн ₽ добавился НДС - 5% или 7% в зависимости от оборота.
Для разработки и тестирования это бьёт особенно сильно: у сервисной компании почти нет закупок, которые можно зачесть. Основной ресурс - это люди, значит и рост нагрузки ложится почти целиком на фонд оплаты труда.
Если вы сейчас сравниваете предложения подрядчиков по аутстаффу и видите, что ставка выросла на 10–15% год к году - это не потому что вендор жадный, просто налоговая база изменилась у всех одновременно.
При выборе между расширением штата и аутсорсом в 2026 году эту статью расходов стоит закладывать заранее📊 | 1 |
| 9 |  С 2026 года в реестр российского ПО попадают только продукты, прошедшие проверку на соответствие требованиям ФСБ и ФСТЭК. При этом около трети крупного бизнеса в России до сих пор работает на закупленном раньше иностранном софте.
Для компаний, которые переходят на отечественный стек, это не уже не простая формальность. Проверка на ИБ - отдельный этап, который нужно закладывать в план перехода отдельной строкой. Практика 2026 года окончательно ушла от сценария "срочно заменить" к управляемому технологическому переходу с обязательным тестированием безопасности на каждом шаге.
Если вы планируете переход на отечественное ПО, вот три пункта, которые обязательно нужно проверить на старте:
1) соответствует ли выбранное решение актуальным требованиям ФСТЭК(с 2023–2024 года они поменялись);
2) заложено ли отдельное время на тестирование ИБ;
3) есть ли в команде, которая ведёт переезд, экспертиза именно в проверке безопасности. | 170 |
| 10 |  Рынок тестирования в России в 2026-м раскололся на два лагеря: "чистый" Manual QA и гибридный SDET - тестировщик, который пишет автотесты и код наравне с разработчиком.
Разница между ними в трёх вещах:
• переход в автоматизацию
• знание языка программирования
• опыт в продуктовой или финтех-разработке.
Ручной тестировщик без этих навыков упирается в потолок карьерного роста раньше остальных. Компании всё чаще ищут не "ручника", а инженера, способного закрыть и функциональное, и автоматизированное тестирование.
Если вы уже в QA или только заходите в профессию, то вот три ориентира в 2026:
✅автоматизация - не доп., а проходка в Middle+;
✅один язык программирования (Python, Java, JS) закрывает 70% вакансий SDET;
✅опыт в продукте или финтехе повышает ценность специалиста больше, чем ещё один сертификат. | 158 |
| 11 |  Сроки сдвигаются, а причина каждый раз новая и неожиданная🧐
"Не учли сложность интеграции..."
"Заболел ключевой разработчик..."
"Оказалось сложнее, чем думали..."
По отдельности все эти причины - обыденность разработки, но если посторяется 3-4 раза подряд - уже закономерность.
Собрали чек-лист из своей практики - те звоночки, с которыми к нам чаще всего приходили заказчики, когда искали новую команду:
• сроки плавают без внятного объяснения
• отчётность приходится выпрашивать
• никто не может сказать, кто конкретно делает задачу
• архитектурные решения принимаются без вас
• тестирование - по остаточному принципу
• "всё под контролем", "мы уже разбираемся" и другие типовые ответы на прямые вопросы
И отдельно - что делать до того, как расторгать договор: как зафиксировать факты, о чём спросить прямо и когда стоит заказать независимый аудит.
Читайте в нашей новой статье → https://clck.ru/3VGocN | 157 |
| 12 |  «Рынок 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. Медианная зарплата в тестировании — около 150 тыс. ₽, в разработке — около 220 тыс. ₽ (Хабр Карьера).
Резкого разворота осенью не будет — компании продолжат нанимать точечно, под конкретный набор навыков, а не «ещё одного QA».
Мы в IT Test как раз ищем таких людей — открытые позиции: ittest.ru/career | 137 |
| 13 |  Тестирование было нашей ключевой экспертизой ещё до того, как мы начали разрабатывать сайты и мобильные приложения. Мы занимаемся этим достаточно давно, чтобы знать: тестировщикам не нужен ещё один красивый интерфейс - им нужно, чтобы рутина не съедала время и инструмент действительно помогал в работе.
Именно это мы заложили в DoQA.
Например, заголовок баг-репорта тестировщик обычно пишет на бегу, просто описывая, что получилось. DoQA сама формирует чёткий заголовок по описанию фактического результата - мелочь, но таких мелочей за день набирается на десятки багов.
Или другая рутина: перечитывать свои же тест-кейсы на полноту и ясность формулировок. DoQA проверяет кейс на атомарность и на ясность цели. Если что-то не так, сразу предлагает правки которые можно применить одной кнопкой.
Ещё одна вечная головная боль QA-лида - доказать, что команда протестировала именно то, что должна была, а не просто накопила гору тест-кейсов. Требования живут в трекере, тесты - в TMS, и без ручной сверки понять реальное покрытие почти невозможно.
В DoQA есть матрица трассировки: она напрямую связывает требования из Jira с тест-кейсами и результатами прогонов, показывает, что осталось непокрытым, а если требование поменялось - помечает связанные тесты статусом «требуется актуализация», чтобы старый результат не вводил в заблуждение.
Документация и подробности на сайте doqa.app | 152 |
| 14 |  "Отдать разработку на аутсорс - значит потерять контроль над проектом". Один из самых живучих мифов у заказчиков.
На практике контроль теряют не из-за формата работы, а из-за того, как он выстроен:
• нет регулярных демо и статус-встреч, поэтому о состоянии проекта вы узнаёте по факту, а не заранее;
• нет доступа к беклогу и трекеру задач, поэтому непонятно, что вообще происходит между созвонами;
• архитектурные решения принимаются без согласования, и вы узнаёте узнаёт о них, когда переделывать уже поздно;
• отчётность даётся «по запросу», а не по согласованному графику, поэтому спрашивать приходится самому.
Знакомая ситуация: спрашиваете на созвоне "почему сдвинулся срок?" и слышите "мы уже работаем над этим".
Дело не в том, что подрядчик плохой или по какой-то причине пытается саботировать работу, просто сам процесс изначально не предполагал конкретной отчётности, этапов согласования и доступов к беклогу или трекеру.
Контроль - это не про то, кто говорит «согласовано» или кого наказать в случае неудачи.
Это про то, видите ли вы ход проекта, знаете ли, что конкретно и как делает ваш подрядчик, и кто с вашей стороны может точно сказать, что и где может сломаться до того, как это станет проблемой.
Поэтому прежде чем подписывать договор с любым подрядчиком, добейтесь внятных ответов на четыре вопроса:
1. Кто конкретно ведёт архитектуру?
2. Будут ли регулярные демо и с какой частотой?
3. Дадут ли вам доступ к трекеру задач?
4. Как будет выстроена отчётность - не "по запросу", а по графику?
Без этих четырёх пунктов контролировать процесс не получится. | 162 |
| 15 |  Найти нормального подрядчика на разработку было непросто и раньше. Сейчас - сложнее вдвойне.
Почти в каждом проекте так или иначе используется AI: где-то Copilot, где-то Cursor, где-то Claude Code, Chat GPT и т.д. И на этом фоне разговор о том, кто реально отвечает за результат, размывается ещё сильнее. А разбираться с тем, как именно написан код, архитектура, как это всё протестировано и т.д. придётся вам.
Мы же расписывали зоны ответственности задолго до того, как это стало общей проблемояй рынка. На старте проекта всегда понятно, кто ведёт архитектуру, кто отвечает за тестирование, кто отвечает за сроки - и почему именно так, а не иначе.
Ещё до старта мы вместе с заказчиком согласовываем отчётность: какая именно, как часто и в каком формате. Это не бюрократия, а способ избежать недопониманий с самого начала.
Если вы устали от созвонов, после которых остаётся больше вопросов, чем ответов — приходите, разложим всё по полочкам.
🌐https://ittest.ru/
🥸 Telegram | 157 |
| 16 |  Тесты стареют быстрее, чем вы успеваете это заметить📉
Если честно, это довольно неприятное открытие — когда понимаешь, что тест-кейс, который прошёл вчера, проверяет то, чего уже нет.
Требование поменяли в трекере полгода назад, никто не заметил, а тест как ни в чём не бывало продолжает зеленеть в отчётах.
Мы это видели на многих проектах — и сделали матрицу трассировки требований, чтобы такое больше не всплывало сюрпризом.
Что она умеет:
- сама подтягивает требования из трекера, руками переносить не нужно
- показывает, что покрыто тестами, а что нет
- если требование меняется по сути — помечает связанный тест: «Требуется актуализация»
- может сразу собрать тест-кейс из контекста требования с помощью ИИ
- работает в обе стороны: статус покрытия видно и в DoQA, и в самом трекере
Требования при этом никуда не переезжают — остаются там, где жили. Мы не тащим вас в новую систему, просто наводим мост между тем, что уже есть.
Почитать подробнее можно у нас на сайте
🌐 https://doqa.app/
🥸 Telegram
🤩 Мы в MAX | 149 |
| 17 |  +1Наш QA Lead Андрей Бракоренко выступил на Summer Merge — антиконференции про айти на берегу Волги 🌊
Формат Summer Merge — не обычный: 3 дня на Русском берегу, доклады, альтернативные активности, концертная программа и явный акцент на work-life balance. Андрей поехал с докладом «Аудит тестирования: как мы лечили QA на финтех-проекте» — про то, как 280 часов аудита превратились в новую модель QA-процессов для клиента, у которого дефекты уходили в прод, несмотря на активно работающую команду тестирования.
Спойлер: классические инструменты аудита пришлось выбросить в первые дни — ни требований, ни тест-кейсов не было. Как выкручивались — Андрей рассказал в докладе.
Вместе с ним ездил Илья Терехин, наш лид разработки — уже в качестве слушателя.
Кстати, если хочется поговорить про аудит QA или тестирование в вашем продукте — Андрей с командой именно этим и занимаются😎
Написать нам:
📧 Почта - office@ittest-team.ru
🥸 Telegram | 217 |
| 18 |  📊Как мы учим тестировщиков точно оценивать задачи — и где это не работает
Наш QA-лид написал на Хабре честный разбор: почему оценки на тестирование почти всегда расходятся с реальностью, и что мы делаем, чтобы расхождение было меньше.
В статье — семь конкретных причин ошибок в эстимейтах, с которыми сталкивается любая QA-команда: туман в требованиях, недооценка дефект-циклов, комбинаторные взрывы, когнитивные искажения и другие. По каждой — решение, которое реально применяли на наших проектах.
Отдельно — честный вывод: подход сработал не везде. На проектах с прямым менеджментом метрика реально работает. На аутстаффе, где наш специалист — точка экспертной поддержки, а не руководитель команды клиента, встроить системный подход в чужую рутину сложнее.
Если работаете с QA-командой и узнаёте свои проблемы в статье — велком в комментарии, обсудим.
👉Читать на Хабре | 213 |
| 19 |  🆘 Что делать, если компания, которая писала вашу основную бизнес-систему, ушла с рынка — а сама система продолжает крутить весь ваш операционный процесс?
Несколько российских сетей коворкингов оказались именно в этой ситуации. Платформа SpacePass — на которой держались онлайн-бронирования, биллинг, СКУД, интеграции с 1С и AmoCRM, личные кабинеты и мобильные приложения резидентов — объявила о прекращении технической поддержки своих клиентов. По нашим оценкам, без сопровождения осталось 15–20 компаний по России.
Часть из них мы взяли на поддержку. Не потому что искали такую работу, а потому что уже знали продукт изнутри — на SpacePass работал наш клиент SOK, и мы давно копались в её архитектуре.
В статье разобрали:
➡️ как заходить в чужой продукт без передачи дел и документации
➡️ почему такая система не умирает сразу, а деградирует по кусочкам — SSL-сертификаты, налоговые ставки, протоколы платёжек
➡️ как выглядит «поддержка», когда ты не писал систему сам
➡️ почему дешевле звать тех, кто уже погружён, чем учить нового разработчика с нуля
👉 Читать статью | 225 |
| 20 |  Написали в блог про то, как развернули корпоративный форк Signal — и почему это оказалось совсем не так просто, как звучит
Signal — open-source. Казалось бы, берёшь исходники и разворачиваешь у себя. На практике это сложная распределённая система с криптографией, кучей зависимостей и нулём документации по самостоятельному запуску.
Мы взялись. Три месяца до первого рабочего запуска, потом два года поддержки и обновлений.
Самое интересное случилось в апреле 2025-го: Intel отключил облачную схему аттестации для SGX-компонентов — критической части инфраструктуры. Старая конфигурация перестала работать. Разработчик, который помогал нам при первом запуске, сам не смог разобраться с новой версией. Мы смогли. И запустили новый SGX-сервис примерно в пять раз дешевле базовой конфигурации.
В статье рассказали: что именно пришлось делать, какие были сложности и в каких сценариях такое решение вообще оправдано (спойлер — не всегда).
👉 Читать статью | 170 |
