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

Привет, Хабр! Меня зовут Анатолий, я руковожу группой автоматизации и управления тестового оборудования в YADRO.

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

Хаотичная работа с тестовыми стендами — это проблема, и я пришел в компанию, чтобы ее решить. Так в YADRO появилась автоматизированная система бронирования тестовых стендов, она же Automated Testing Facility (ATF). В статье расскажу, что она умеет, на каких технологиях основана и почему под наши задачи не подошел Jenkins

Привет! Меня зовут Елена Поплоухина. Я отвечаю за развитие сообщества тестировщиков в ГК «Юзтех». В этой статье я хочу поделиться набором инструментов, которые полезны для ручного тестирования веб-приложений. Этот список собран на основе рекомендаций участников нашего сообщества.

Все ссылки и информация по инструментам актуальны на момент выхода статьи.

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

Почему отчётность, статистика и логирование в Go-автотестах превращаются в костыли — и как плагинная модель позволяет вынести инфраструктуру за пределы тестов.

В статье разбираем практический маршрут на REST Assured 6.0.0 и JSON Schema: как закрыть структуру ответа одной проверкой, как сделать схему по-настоящему строгой и где в этой связке спрятан капкан, из-за которого схема с условной логикой выглядит рабочей, но не проверяет ничего.

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

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

Всех приветсвую! В данной статье я не буду пояснять какие-то сложные вещи касательно нагрузочного тестирования. Просто хочется поделится своей болью, пронесенную сквозь года в разных enterprise системах. Может я не один такой?

Итак, представьте, что вы инженер по нагрузке...

40-60% времени современных QA-команд тратится на диагностику сбоев в тестах. Эта проблема настолько серьёзна, что сейчас активно разрабатываются практики сокращения размеров тестовых сюит, Майкрософт рекомендует при триаже не разбирать каждое падение по отдельности, а кое-кто советует «стохастический подход» к разбору ошибок, при котором команды не тратят время на разбор каждого падения.

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

Дашборд зеленеет, число багов падает, команда получает похвалу — а через пару недель прод ловит инцидент на ровном месте. Так бывает, когда метрики дефектов становятся целью для отчёта и начинают подменять реальное управление качеством. В статье — шесть типовых ошибок: от количества багов как личного KPI до доли переоткрытых задач, которую легко обойти красивой статистикой.

На примере FastAPI-чата показываю, как выстроить автотесты для API с двумя транспортами: REST используется для подготовки состояния, WebSocket — для проверки событий. В статье разбираем архитектуру тестов на Python: клиенты, фикстуры, Pydantic-схемы, контрактные проверки, Allure и CI/CD.

Привет, Хабр. Я Александр, мне 33. Хакинг у меня хобби, а не работа: CTF, Hack The Box, иногда багбаунти по выходным. И каждый раз одно и то же.

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

Команду собрал. А дальше? nmap отработал, передо мной открытые порты — и я завис. За что хвататься? В каком порядке? Это знание у каждого где-то в голове, и достаёшь его каждый раз заново.

Словарь. И где он лежит-то. /usr/share/wordlists? seclists? А подкаталог? Опять ls, find, вспоминаешь путь, который вбивал сто раз.

Пейлоад. Лезешь в PayloadsAllTheThings — а там стена. Какой брать? На каком этапе? Что выстрелит, а что лежит для галочки? Непонятно.

И так весь тест размазан по тридцати вкладкам. HackTricks, PayloadsAllTheThings, GTFOBins, revshells, рядом гугл с переводчиком — половина же на английском. Плюс папка своих заметок.

Бесит. Особенно на вебе: нашёл точку, надо быстро прогнать пейлоады — а ты вместо дела вспоминаешь, где у тебя что лежит.

В какой-то вечер я психанул и начал сваливать всё нужное в одно место. Локально, на русском, поиск по одной кнопке. Оно разрослось, и я сам не заметил, как это стало отдельным проектом. Выложил в опенсорс. Назвал ARS3NAL — тут без фантазии, арсенал он и есть арсенал.

Довольно часто процессы тестирования внутри крупных продуктов, рассчитанных на миллионы конечных пользователей, превращаются в «черный ящик». Каждый участник процесса разработки видит лишь свой узкий участок: аналитики уверены в точности и полноте требований, разработчики уверены в коде, инженеры по функциональному тестированию — в отсутствии багов в своих подсистемах, администраторы — в настройках сервера. Всем участникам кажется, что все работает нормально, но это ощущение бывает обманчивым. 

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

Привет, Хабр! Меня зовут Михаил Володин, я ведущий инженер отделения нагрузочного тестирования. В этой статье расскажу о реальном кейсе, когда по отчетам с продуктом все хорошо, а пользователи все равно жалуются. Нам с командой нужно было дать объективную оценку: достаточно ли текущих методов, подходов и инструментов, где скрываются слепые зоны, необходимо ли что-то менять. 

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

Каждый ноет на ретро. Мы научились ныть так, что работать стало комфортнее и эффективнее. В статье расскажу, что нам помогло.

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

Представьте: вы даёте задачу, а интеллект внутри IDE сам всё делает. Без интернета, без копилки токенов. Видит весь проект а не конкретный файл. Это уже реальность.

В чем отличие агента от чата - ассистента?
Всё просто они работают по схеме запрос-ответ. Спросил, получил текст и дальше сам разбирайся. А агент - это совершенно другая история. Агент сам планирует, что делать, сам использует инструменты (редактировать файлы, выполнять команды в терминале, искать по проекту), помнит весь контекст сессии и, что важно, умеет реагировать на ошибки и корректировать свои действия на ходу. Cline в IntelliJ именно такой. Он реально работает в вашей среде, почти как живой коллега.

Привет, Хабр! Меня зовут Андрей Орлов, я QA‑инженер в команде Tarantool Database, VK Tech. Я занимаюсь функциональным тестированием: проверяю новые фичи и изменения, поддерживаю и развиваю автотесты, разбираю инциденты, анализирую логи и метрики. Нагрузочное тестирование и стресс‑тестирование тоже входит в мои задачи — в том числе для проверки поведения Tarantool Database на больших конфигурациях. В этой статье я расскажу, как мы организовали и провели тестирование Tarantool Database на 640 инстансах, какие подходы и инструменты использовали и какие выводы сделали.

Привет, Хабр! На связи Екатерина Серикова и Глеб Дмитриев, мы QA-инженеры в команде Авито Sales. В этой статье мы расскажем, как выстроили процесс обеспечения качества в Распродаже, где сроки нельзя сдвигать, а нагрузка на корчасть почти 2 млн RPM, а цена бага очень высока.

Это не история про «идеальный процесс». Она скорее про рабочую систему, которая помогает не сгореть команде и не терять качество, когда QA в проекте один, а разработчиков восемь.

Распродажа на Авито, где 120 млн пользователей, — это всегда высоконагруженные сценарии без права на ошибку. Поэтому в статье мы объясняем, почему важно подключать QA ещё на этапе идеи, а не тестирования. Перекладывание какой части задач на разработку только ускоряет общий процесс? Что можно скормить ИИ, а что следует выполнять самим? Для чего разделять Seller и Buyer контуры?

Здесь всё на личном опыте, по делу и понятно.

Хотите не забывать детали диалога или то, что вас просили купить в магазине? Конечно, можно по старинке открывать блокнот в телефоне или чат в избранном и записывать все руками, но в потоке задач это неудобно. Гораздо проще надиктовать мысли голосом или записать разговор, а расшифровку доверить сервису. 

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

Tantor Postgres 18 - масштабный релиз СУБД, за которым стоят месяцы тестирования, сотни часов нагрузочных прогонов и десятки исправлений, о которых пользователь никогда не узнает просто потому, что они были найдены и устранены до выхода версии. Александр Симонов, руководитель направления развития 1С в "Тантор Лабс", рассказывает, как устроен процесс тестирования изнутри - почему одного эталонного прогона недостаточно, что делать, когда ванильный PostgreSQL 18 ломает собственные оптимизации, и как Tantor Postgres приближается к той планке, которую MS SQL Server держал годами.

Всем привет! Меня зовут Олег Малышев. Я один из лидеров стека тестирования в компании «ТехВилл»

Мы продолжаем разговор о том, как применять ИИ в тестировании. В этой статье расскажу, как мы пишем API-автотесты с помощью OpenAPI Generator, Cursor/Claude Code и автоматически считаем покрытие по Swagger через swagger-coverage.

Раньше я уже записывал большое двухчасовое видео по Cursor, где показывал в том числе, как мы генерируем автотесты. Но с тех пор подход немного изменился: мы сильнее завязались на OpenAPI-контракт, добавили Swagger Coverage, JSON-отчёты для LLM и специальные skills для генерации недостающих тестов.