Тестирование IT-систем *

Ближайшие бесплатные вебинары:

🎬 «Как ИИ уже изменило тестирование ПО»
14 сентября, 18:00–19:00 (Мск).
Разберём, что реально делегировать, где нужна экспертиза человека и сколько это стоит. Отдельно обсудим роль QA как дирижёра ИИ-процессов, контроль стоимости токенов и логирование, а также инфраструктурные задачи и кейсы автоматизации рутины. В финале — риски: безопасность данных в LLM, рост затрат, организационные сложности и снижение компетенций при чрезмерной зависимости от ИИ.
✍️ Записаться

🎬 «Один SQL над Iceberg, PostgreSQL и ClickHouse: как Trino выполняет федеративные запросы, и где они начинают тормозить»
15 сентября, 17:00–18:00 (Мск).
Один SQL над Iceberg, PostgreSQL и ClickHouse: как Trino выполняет федеративные запросы и где они тормозят. На живом примере с EXPLAIN ANALYZE — план выполнения и способы ускорения, от фильтрации и материализации до вычислений в источнике. В финале — сравнение с PostgreSQL/Greenplum, ClickHouse и Spark SQL и что меняется в проде.✍️ Записаться

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

На круглом столе QA-days эксперты Okko, ИнфоТеКС, Piter QA прошлись по самым острым темам тестирования:

• Доверие к QA — как заслужить и не потерять

• Рутина — враг или союзник?

• Кросс-командное vs кроссплатформенное тестирование — в чём разница и как организовать без боли

• Интеграционное тестирование — где ломается чаще всего и как чинить

• Shift Left — почему на практике внедряется так тяжело, несмотря на очевидную пользу.

Смотреть запись

Ещё больше о мероприятиях — в нашем TG-канале.

QA-дайджест за июль-август 2026

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

📊Рынок
Вышел The State of Testing™ Report 2026 от PractiTest. Статистика неутешительна: 56,4% QA-команд по-прежнему оценивают по покрытию тестами и 40,1% — по покрытию автоматизацией, тогда как бизнес-влияние учитывают лишь 8,6% организаций. Это явный перекос в сторону объема работы, а не ее ценности для продукта. Похожий перекос виден и в применении ИИ: 70% команд используют его для генерации тест-кейсов и только 19,9% — для стратегического риск-анализа. Самыми передовыми инструментами сейчас называют Selenium и Playwright, при этом за владение вторым соискателям дают на 38% больше денег в год. Впрочем, возможно, это всего лишь корреляция. 

Еще забавное: отчет Perforce/Perfecto по DevOps и ИИ в тестировании свидетельствует, что 66% компаний отметили рост общих затрат после внедрения ИИ. При этом комплексный трекинг затрат на ИИ-тестирование настроен лишь у 43% — то есть тестирование с использованием ИИ растет быстрее, чем контроль затрат над ним. 

🔧 Интересные материалы на Хабре
Команда из InfoWatch рассказала, как ввела регламент стыковки ручного и автотестирования для построения единой системы контроля качества. Можно утащить к себе в практику таблицу этапов/артефактов/критериев и список ошибок, ну и саму логику стыковки. 

Ozon Tech поделился Testo — open source фреймворком для E2E-тестов на Go (Apache-2.0, 60 тыс. тестов, 500+ сервисов). В статье описывают, как это меняет работу: теперь инженер пишет проверку как обычно, а Testo сам красиво оформляет отчет, параллельно запускает тесты на сотнях машин, повторно прогоняет упавшие и передает данные между этапами. Перспективно для тех, кому надо писать и поддерживать большие end-to-end-тесты на Go.

Ребята из 2ГИС описали свой опыт тестирования приложения «в поле», ведь баги геопозиции почти невозможно воспроизвести на тестовом стенде. Описанные практики возможно пригодятся тем, чьи продукты связаны с навигацией и страдают от «глушилок».

🤖Про агентов
Коллеги из TestOps построили «Агента Смита» — платформу агентной правки багов с целью «ноль багов в бэклоге». Суть следующая: выстраивается цепочка независимых шагов, каждый из которых создает артефакт, на который опираются последующие шаги. Итог: 100 прогонов, 76 закончились открытым мерж-реквестом, 62 из них влиты (81,6%). Из влитых 53 ушли в основную ветку без единой правки человеком. Можно утащить к себе логику шагов и потестить на своих кейсах. 

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

💼 Для карьеры
Вышел анонс осенней конференции Heisenbug 2026, обещают 36 докладов от гигантов рынка. От нас там выступит Александр Волков, который проведет воркшоп по тому, как собрать своего QAI-агента. 

Также анонсировали SQA Days / 39. Цены на участие немного кусачие, поэтому если хотите попасть, самое время начать согласовывать затраты с руководством.

У нас появилась целая пачка горячих вакансий, которая ждет ваших откликов:

• Fullstack QA (Infra Agent)

• Fullstack QA (IaaS Terraform)

• Fullstack QA (Distributed Train)

• Fullstack QA (Managed RAG)

• Fullstack QA (ML Inference)

👉Подписывайтесь, чтобы не пропустить следующую порцию пользы. 

Как не провалить пилот ESB: разберем два реальных сценария на онлайн-конференции

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

На практике вопросов гораздо больше.

• Что именно включать в пилот?

• Какие сценарии действительно показательны?

• Нужно ли проверять только функциональность или еще производительность, мониторинг и удобство сопровождения?

• Стоит ли отдавать пилот интегратору или пробовать силами внутренней команды?

15 сентября в 11:00 вместе с DATAREON проведем онлайн-конференцию «Архитектурная лаборатория: как выбрать ESB под вашу ИТ-архитектуру». Разберем не только возможности платформы, но и то, как организовать пилот так, чтобы он действительно помог принять решение.

Что будет в программе

Сергей Скирдин, технический директор «Белого кода», расскажет:

• как сегодня выглядит российский рынок шин данных;

• какие критерии стоит учитывать при выборе ESB;

• в чем преимущества DATAREON Platform;

• зачем пилотировать платформу на реальном ИТ-ландшафте;

• какие задачи стоит закладывать в пилот.

Иван Макушов, аналитик Ikon Tyres, поделится опытом пилота с внешним подрядчиком:

• как в компании подходили к выбору новой интеграционной платформы;

• какие технические требования сформировали;

• какие сценарии включили в пилот;

• на что стоит обратить внимание при работе с интегратором..

Дмитрий Сидоренков, архитектор 1С «Уральской Агропромышленной Группы», расскажет про другой путь — пилот и дальнейшее внедрение внутренними силами:

• почему одного обучения недостаточно, чтобы начать реальный проект;

• какие специалисты нужны внутри команды;

• почему хотя бы один человек должен быть глубоко погружен в проект;

• где самостоятельной команде все же полезна внешняя экспертная поддержка;

• как перейти от первого работающего обмена к самостоятельному развитию интеграций.

По сути, сравним два сценария:

пилот с подрядчиком
и
пилот внутренней командой.

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

15 сентября, 11:00 по МСК

Участие бесплатное, нужна регистрация.

Регистрация

Еще одна интересная форма тупости у нейросеток (сначала Claude Sonnet 5, потом Claude Opus 5): оно не понимает, что если устройство (нетривиальное, то есть у которого есть внутреннее состояние) выдало глюк на тесте в первую секунду работы, то бесполезно минимизировать количество глюков, которое оно выдаст в следующий час. Оно уже глючное, нужно исправлять первый глюк. Прогресс - это не “было 100 глюков в час, стало 80”, а “был глюк на первой секунде теста, а теперь глюк появился только на второй”.

Дал нейросетке задание: исправить ошибку в сгенерированном ею модуле на языке описания аппаратуры SystemVerilog. Модуль погружен в тестовое окружение которое проверяет работу модуля против его модели (тоже написанной на SystemVerilog). На вход и модуля и модели подаются одни и те же входные транзакции (stimuli), после чего у них сверяется ответы. Ответы могут приходить в несколько разное время, но это не имеет значения, потому что перед проверкой они складируются в очередях. Как и исходные транзакции до отправления, чтобы не сравнивать детали латентности handshake-ов.

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

И вот оно провело ночь гоняя симуляции и минимизируя счетчик глюков. Ну первую ночь я бы простил. Я сказал “мерило прогресса - не счетчик глюков, а что первый глюк возникает позже”. Но оно потом это забыло и снова провело ночь минимизируя счетчик глюков.

Это из той же оперы как “если ты услышал что часы на башне пробили 13 раз, то скорее всего неверным является не только 13-й удар колокола, но и 12 предыдущих”. Или если у тебя syntax error в коде на Си в строке 100, то зачем проводить всю ночь пытаясь минимизировать количество syntax errors в последующих строках?

Друзья!

Перед вами моя новая фантастическая повесть «Королев ИИ»: инженеры нооэры», которая родилась не на пустом месте. Она выросла из моей многолетней работы в сфере информационных технологий и бесценного опыта, который я получил во время работы над созданием Центра разработки и внедрения сильного и прикладного искусственного интеллекта МГТУ им. Н.Э. Баумана в 2021 году[1], а также из опыта работы над проектом создания научно-образовательной платформы «Королев ИИ».

Эта повесть выходит в преддверии важного события. В сентябре 2026 года в МГТУ им. Н.Э. Баумана стартует полноценное использование научно-образовательной платформы «Королев ИИ» для всех сотрудников, преподавателей и студентов. По нашей задумке, платформа должна стать, в некотором смысле, «фундаментом» нашего университета, в рамках реализации концепции «Университет 4.0» и будущей концепции, которую мы назвали «Нейроуниверситет» (над которой мы уже работаем). Сейчас, у нас большой потенциал и задел по ноу-хау, новым задачам и новым ИИ-сервисам для университета, по научным открытиям и публикациям полученных результатов, которые мы планируем реализовать в ближайшее время.  И, — это только начало.

В этой повести я попытался заглянуть за горизонт текущего момента. Попытался представить, какими могут быть новые технологии ближайшего будущего и каким может стать наш мир, где искусственный интеллект будет не просто инструментом, а станет незаменимым помощником человека, чьи технологии позволят человеку быть не просто «продвинутым» пользователем интеллектуальной автоматизированной системы, а помогут стать настоящим творцом и исследователем (то есть, так называемым, инженером нооэры), использующим знания и опыт для творчества, созидания и сохранения нашего мира и, возможно, покорения Солнечной системы.

Эта повесть — моё приглашение к размышлению. К размышлению о сегодняшнем дне и о будущем нашей цивилизации.

Я посвящаю ее студентам и молодым учёным, изобретателям и энтузиастам. Я посвящаю ее сегодняшним людям завтрашнего дня. Тем, кто не боится мечтать и воплощать мечты в жизнь. Тем, кто своими руками, своим умом и своим упорством создаёт будущее.

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

2126 год начинается 1 сентября 2026 года.

Ваш Александр Чесалов.

QA-эксперт Авито о том, почему вход в IT через тестирование больше не работает

Всем привет! Гостья нового выпуска AviTalk — Соня Каребина, QA-эксперт Центра экспертизы обеспечения качества в Авито. До IT у неё были инженер-нефтяник и администратор фотостудии — то есть путь в тестирование получился совсем не прямым. Ведущий выпуска — Виктор Раев, руководитель разработки юнита Services Base.

Говорим о том, почему в тестировании нет универсального ответа «релизить или не релизить» и как QA оценивает риски для пользователей и бизнеса. Разбираемся, почему умение договариваться для тестировщика важно не меньше технической экспертизы, и каким становится процесс, когда человек и AI работают в связке. А ещё — про волонтёрство, эмоциональное выгорание, вязание, двести комнатных растений, мечту о Марсе и принцип, который в своё время помог Соне сменить профессию.

Смотреть выпуск:

🔵 VK Видео
📺 YouTube
📌 RuTube

AviTalk — шоу толковых людей. Приглашённые гости — сотрудники Авито из разных дирекций и команд, которые делятся экспертизой и рассказывают о своём профессиональном пути.

Баг в проде — кто виноват?

На QA-days: Оkko, ИнфоТеКС и Piter QA эксперт из Okko показал, как в компании ZBP учитывают не только критичность бага, но и причины его пропуска. Результат: багов первой категории стало в 2,5 раза меньше. Просто показали разработчикам, сколько они выкатывают.

• Смотреть запись доклада

Ещё больше о мероприятиях — в нашем TG-канале.

Эволюция ченжлога на сайте

Многие из вас предлагают идеи по развитию продуктов и следят за обновлениями. Чтобы отслеживать релизы было проще, даже если пропустили дайджест, мы переделали старый ченжлог в «Журнал обновлений». В нем записана вся история релизов, изменений и исправлений багов с лета 2024 года.

Что появилось:

1️⃣ Блок «Запланировано» — что сейчас в работе и выйдет в ближайшее время. Прежде чем нести фичу в «Идеи», стоит заглянуть туда.

2️⃣ Поиск — если нужно узнать, добавили ли нужные AI-модели или новую ОС в маркетплейсе.

3️⃣ Теги — показывают, к каким сервисам относится релиз.

4️⃣ Фильтр — по месяцам и сервисам, работает и вместе: например, все обновления S3 за июль.

А если следить за релизами удобнее в Телеграме, обновления дублируются в нашем канале @twc_changelog

Заглянуть в журнал обновлений →

QA без рутины: нагрузка, автоматизация, AI и новые инструменты

В тестировании регулярно появляется новая задача, к которой вчера ещё можно было не прикасаться: проверить сервис под нагрузкой, автоматизировать UI и API, разобраться с трафиком или подключить ИИ к автотестам.

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

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

Нагрузочное тестирование

• 13 августа, 20:00. «Минимум для старта: как провести свое первое нагрузочное тестирование». Записаться

Автоматизация тестирования

• 20 августа, 20:00. «Как ускорить создание автотестов с помощью локальных ИИ‑моделей». Записаться

• 3 сентября, 20:00. «UI и API тестирование с Java и Playwright». Записаться

• 22 сентября, 20:00. «Playwright JS: как быстро начать писать автотесты?». Записаться

• 22 сентября, 20:00. «Автоматизация управления трафиком с mitmproxy». Записаться

ИИ в работе тестировщика

• 2 сентября, 20:00. «ИИ для тестировщика: инструменты, которые уже меняют профессию». Записаться

• 8 сентября, 19:00. «Автотесты 1С через ИИ: от запуска до контроля результата». Записаться

Game QA

• 24 августа, 20:00. «Тестирование игровых уровней: как находить ошибки, которые влияют на игровой опыт». Записаться

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

А если хочется посмотреть на QA шире — читайте материалы:

• «Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)» — о том, почему качество всё сложнее подтверждать только набором проверок перед релизом и как меняется роль QA в постоянно меняющихся системах.

• «6 ошибок в метриках дефектов, из‑за которых QA теряет контроль над качеством» — о ситуациях, когда дашборды выглядят хорошо, количество багов снижается, а реальное качество продукта при этом может ухудшаться.

Полный список бесплатных уроков августа смотрите в дайджесте.

Подборка материалов: что почитать тестировщику 

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

➡️ Мифы о тестировании

Какие ожидания от профессии расходятся с реальностью и чем на самом деле занимается тестировщик.

➡️ Тестирование верстки

На что обращать внимание при проверке интерфейса кроме соответствия макету: тексты разной длины, переносы, отступы, состояния элементов и работа с DevTools.

➡️ Как начинающему тестировщику выстраивать рабочий диалог в команде

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

➡️ Инструменты ручного тестирования

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

➡️ Как тестировать требования

Как находить проблемы еще до разработки: проверять требования на полноту, однозначность, выполнимость и использовать для этого вопросы, чек-листы, прототипы и другие техники.

Сохраняйте подборку, чтобы материалы всегда были под рукой ❤️

Привет! На связи снова QA-сообщество 2ГИС. Подготовили новый дайджест свежих релизов.

➡️ Playwright 1.62

Появилась новая модель тестирования компонентов — stories и galleries. Теперь можно быстро создавать сценарии с конкретными параметрами и моками, а затем запускать их из галереи. Добавили возможность прерывать долгие операции через AbortSignal. Скриншоты теперь поддерживают формат WebP с разным качеством. Улучшены фильтры тестов и добавлен режим изолированных повторов для минимизации мешающих друг другу тестов. Обновились API браузера и сетевых операций. Debian 11 больше не поддерживается.

➡️ uv 0.12.0

Усилена безопасность и совместимость: теперь запрещены устаревшие форматы архивов и опасные wheel-файлы, способные нарушить виртуальное окружение. Возвращена упаковка проектов по умолчанию с uv_build. Улучшена проверка хэшей зависимостей и работа с сертификатами. Добавлено много новых стабилизированных функций и исправлений.

➡️ Robot Framework 7.5b1

Поддержка документации в Markdown и Google Style форматах облегчает создание описаний ключевых слов. Консольное логирование расширилось — теперь можно использовать собственные логгеры. Появилась возможность запускать тесты прямо из Markdown-файлов. Несколько мелких правок и исправлений.

➡️ Python 3.15.0b4 (бета)

Финальный бета-релиз с важными исправлениями и новинками: ленивые импорты для ускорения старта, новые встроенные типы frozendict и sentinel, усовершенствованный JIT и UTF-8 по умолчанию. Многие мелкие улучшения и большая стабильность.

➡️ FastAPI 0.141.x

Исправлены ошибки с фоновыми задачами и заголовками. Появилась удобная функция app.frontend(check_dir="auto") для быстрой локальной разработки с fastapi dev. Улучшена поддержка SSE и JSONL стриминга.

➡️ Ruff 0.16.0

Значительно расширился набор правил линтинга — теперь по умолчанию включено 413 проверок вместо 59. Добавлена поддержка автоформатирования Python кода внутри Markdown. Добавлены новые форматы комментариев для подавления предупреждений и улучшен вывод исправлений.

Что из этих релизов уже интересно вам? Где планируете попробовать что-то новое? Напишите в комментариях. И заглядывайте в наш канал, чтобы быть в курсе других активностей и мероприятий для тестировщиков.

Лишнее поле в ответе, которое никто не замечает

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

По документации ответ выглядит так:

{
  "traceId": "7c2a8410-56f2-4f59-b921-202607230001",
  "orderId": "ORD-2026-0723-001",
  "status": "CREATED",
  "customerId": "C-1042",
  "pricing": {
    "subtotal": 51960,
    "discount": 5196,
    "total": 46764,
    "currency": "RUB",
    "vatAmount": 0
  }
}

А это то, что реально пришло со стенда:

{
  "traceId": "7c2a8410-56f2-4f59-b921-202607230002",
  "orderId": "ORD-2025-0723-001",
  "stats": "CREATE",
  "customerId": "C-1042",
  "pricing": {
    "subtotal": 51960,
    "discount": 5196,
    "total": 46764,
    "curency": "RU",
    "price": 46764
  }
}

Засеките тридцать секунд и посчитайте расхождения. Девять полей, глазами — ровно так, как это делается в реальной задаче.

⁂

⁂

⁂

Восемь!

1. traceId заканчивается на 0002, а ждали 0001 — ответ пришёл не на наш запрос.

2. В orderId стоит 2025 вместо 2026.

3. Поля status нет: вместо него stats,

4. значение CREATE вместо CREATED.

5. Поля currency нет: вместо него curency,

6. значение RU вместо RUB.

7. Поле vatAmount пропало совсем.

8. Появилось поле price, которого в документации нет.

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

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

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

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

Собирал я это без кода, в своём настольном приложении под Windows. Указываешь путь к параметру, оператор, ожидаемое значение из документации, при желании тип данных — и всё. Запускается руками, из CI не работает, так что если у вас уже есть автотесты и человек, который их пишет, вам это неинтересно, у вас задача решена лучше.

Мне сейчас не хватает взгляда со стороны, особенно ручных тестировщиков и аналитиков. Если вы тоже проверяете API руками и автотестов у вас нет, расскажите в комментариях, как вы ловите такие расхождения. А если захочется посмотреть на инструмент вживую, напишите мне, я покажу и дам доступ, он бесплатный.

Вышел 9-й номер журнала Paged Out (#8 выпустили в июне), который включает в себя различные материалы на тему этичного хакинга и информационной безопасности. Издание публикуется в формате: 1 страница — 1 статья. Все остальные Paged Out выпуски можно скачать с сайта проекта.

Как делать ИПР для сотрудника: 8 правил от эксперта Okko

На QA-days: Оkko, ИнфоТеКС и Piter QA спикер из Okko поделился подходом к формированию траектории развития QA-специалиста через индивидуальные планы развития (ИПР). Доклад поможет выстроить систему, где сотрудники растут с интересом, а не «под кнутом».

Забирай 8 готовых правил в работу.

• Смотреть запись доклада

P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.

Представлен исследовательский проект STOLEN COMPUTE. Это каталог обнаруженных в сети открытых ИИ-серверов, часть из которых по разным причинам оказалась оставлена без защиты, включая ресурсы с ИИ-моделями Kimi 1T и DeepSeek V4.

Безопасность для «чайников»: зачем обычному тестировщику знать про уязвимости

На QA-days: Оkko, ИнфоТеКС и Piter QA эксперт из Гринатом поделился простыми, но важными вещами: «На волне вайб-кодинга безопасность стала проявлять себя всё ярче. Тестирование безопасности постепенно внедряется в процессы обычных тестеров».

Узнай, как QA может влиять на безопасность продукта.

• Смотреть запись доклада

В нашем TG-канале рассказываем о технических мероприятиях и обсуждаем подборки на технические и ИБ темы.

Адриан Мастронарди (занимается созданием и управлением инженерными организациями, стоящими за выпуском ПО) выпустил книгу под названием «Полсекунды». В ней подробно рассматривается попытка создания бэкдора в xz в 2024 году. Книга распространяется бесплатно под (несвободной) некоммерческой лицензией CC, запрещающей создание производных работ.

Публикации про инцидент с xz на Хабре:

• «Можно ли было обнаружить бэкдор xz при более продуманной работе с пакетами в Git и Debian?»

• «Бэкдор в xz нашли из‑за замедления работы sshd в полсекунды».

Тёмные века в теории тестирования

Всем привет, хочу поделиться некоторым наблюдением над инфополем в тестировании. На мой взгляд, после имперского расцвета мы лет 10-15 как вступили в тёмные века. В начале 2000-х Рекс Блэк и компания знатно потрудились над пропагандой единого глоссария, он стал общеупотребимым и более-менее исчерпывающим.

Если раньше раздробленность в терминологии и классификациях можно было встретить только в тестировании производительности, каждый крупный вендор (Microsoft, IBM, Google) придумывал свою иерархию, то теперь каждая заметная статья и/или перевод оной стремится ввести свой "уникальный" термин. Если в "имперские времена" можно было только у Microsoft прочитать про Capacity testing, за этим просматривалась некоторая логика - вендоры предлагали с терминологией свои фреймворки и подходы - то сейчас все чаще ловлю себя на мысли, что затруднительно сделать вывод о том, зачем совершенно не новаторские процессы описывают новыми терминами. Тем временем многие до сих пор путают integrated и integration...

Может мне кто-нибудь объяснить в чем "shift left" отличается от забронзовевшего раннего тестирования (early testing)? Чем модный концепт "quality gates" не просто набор "exit criteria"? T-shaped модель вполне укладывается один из 7 базовых принципов концепции тестирования - тестирование зависит от контекста, знание контекста (в том числе предметной области) необходимо для составления грамотных тестов.

Примеры можно множить и множить. А как вам кажется, имеет ли смысл кипа новых или относительно новых терминов?

Невидимый балласт: тесты, которые уже мертвы

«Иллюзия безопасности» — когнитивное искажение, заставляющее нас цепляться за мёртвые тесты. Мы боимся удалять, потому что кажется: они ещё пригодятся. На самом деле они только засоряют прогоны и снижают доверие к оставшимся проверкам.

Эксперт из Nexign на QA-days разобрал, как избавиться от балласта: чеклист, метрики и честный разбор ошибок.

• Смотреть запись доклада

В нашем TG-канале рассказываем о технических мероприятиях и обсуждаем подборки на технические и ИБ темы.