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

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

Меня зовут Игорь Попов, я директор департамента верификации и контроля качества в YADRO. Далее я простыми словами расскажу, что такое hardware QA: где мы режем, замораживаем, зачем смотрим, загорается ли лампочка по команде BIOS — и что делаем, если нет. Если ты джун или только начинаешь разбираться в «железе», статья поможет понять, подходит ли тебе такая работа и в чем она на самом деле заключается.

Привет! На связи разработчик Максим и инженер по качеству Евгения из Т-Банка. Как-то мы задумались о переходе на TBD, чтобы избежать develop-ветки со всеми вытекающими. 

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

В этой статье мы поделимся опытом перехода на TBD: планом внедрения и вопросами, с которыми мы столкнулись.

Cтатья пригодится инженерам уровня middle и ниже и тимлидам. Для senior-инженеров статья не будет откровением, но надеемся, что станет местом для обсуждения нюансов внедрения или возможностью посмотреть на процесс с точки зрения QA. 

Погнали!

Привет, Хабр! Проблема рассинхронизации автотестов и тестовой документации знакома многим. Код постоянно меняется, а кейсы в Confluence — нет. В итоге документация становится бесполезной, а время команды тратится на выяснение того, что же на самом деле проверяет тот или иной тест.

Есть занятия, которые наполняют жизнь QA-инженера особым, экзистенциальным смыслом, и ручное ведение тест-кейсов, бесспорно, одно из них. Этот медитативный ритуал — найти нужную страницу в Confluence, сверить её с кодом, осознать их полную асинхронность, глубоко вздохнуть и начать творить — несравненно закаляет дух. Но, увы, в какой-то момент безжалостные требования бизнеса к скорости заставили меня пожертвовать этим священным процессом и, скрепя сердце, написать скрипт, который делает всю эту замечательную работу за меня.

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

(Статья — результат со вместной работы с Максимом Степановым)

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

Связанный код, который сложно поддерживать и расширять, сложно и тестировать. Как сказал Боб Мартин: 

«Тестируемый код — синоним разъединённого кода»

А значит, тестируемость может быть маркером хорошей архитектуры. Именно это мы и попробуем здесь продемонстрировать.

Мы напишем тесты для примитивного скрипта на Python, который проверяет IP пользователя, определяет их регион и сообщает текущую погоду в регионе. Нас будет интересовать, как эти тесты заставят нас изменить код. Они, как расчёска, помогут нам методично разобрать проблемные места, чтобы код (как и волосы) стал гладким и послушным. Полный пример доступен здесь, каждый основной шаг находится в отдельной ветке.

В первой части статьи мы сделаем простейшее преобразование — разобъём скрипт на отдельные функции, а потом выясним, какие недостатки кода нам пока не удалось устранить. Во второй части мы от них избавимся с помощью разъединения зависимостей и модульной архитектуры. Поехали!

Если вы используете Allure, то знаете: отчёты могут быть разными: с фильтрами, деревом фич, ссылками на баги, а могут быть унылой простынёй из сотен тестов без смысла и структуры.

Всё зависит от того, как вы помечаете тесты. Allure даёт мощную систему аннотаций, и если её использовать с умом — отчёт превращается в полноценный инструмент для анализа и коммуникации.

Ниже 6 уровней аннотаций, которые помогают держать тестовую базу в порядке. Без перегруза — только то, что действительно работает.

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

В этом руководстве мы рассмотрим типы тестирования производительности API, ключевые проблемы и решения, а также расскажем, как на основе метрик производительности принимать осмысленные решения.

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

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

Текст подготовлен по материалам выступления приглашенного спикера внутри компании.

Привет, Хабр! Представьте ситуацию: вы нашли крутой сервис, регистрируетесь, вводите свой email my.name+coolservice@gmail.com (ведь вы, как и я, любите порядок во входящих) и… получаете ошибку «Некорректный email». Знакомо? Уверен, что да.

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

При масштабном веб‑парсинге прокси — это не просто «много дополнительных IP адресов»: это ключевой компонент, позволяющий обходить защиты сайтов и распределять нагрузку. Без продуманной системы прокси, вы будете тратить все время на реанимацию или замену заблокированных IP адресов. Проблемы могут возникать не только из‑за количества запросов, но и из‑за их распределения и автоматизации: при переходе к большим объемам критичен переход от «одного рабочего скрипта» к распределенной архитектуре. 

Привет! Я Соня Ожерельева — тимлид в команде Monetization Efficiency в Авито. В статье расскажу про новый сетап A/B-теста, который мы использовали при тестировании системы Уровень сервиса на Авито. Он, как и A/B-тест по регионам, позволяет измерять влияние как на покупателей, так и на продавцов. При этом MDE нашего сетапа в 2 раза ниже, чем у регионального. Материал будет полезен аналитикам любых грейдов.

Разбираемся, как организовать нагрузочное тестирование на Python с Locust — с сидинговыми сценариями, кастомными API-клиентами на HTTPX, конфигурацией через Pydantic и автоматическим запуском в GitHub Actions. Всё — на практике, с архитектурой, фреймворком и публикацией отчётов в GitHub Pages.

Привет! Меня зовут Евгений. Я — Full-Stack QA Engineer в Devscribed и сегодня хочу поделиться своим экспериментом — QA Mentor Bot. Это Telegram‑бот, который отправляет в телеграмм группу случайные вопросы по тестированию и сразу же генерирует на них развёрнутые ответы с помощью AI. В этой статье я расскажу, как устроен проект и с какими «подводными камнями» столкнулся в процессе разработки.

Поиск работы в IT — настоящий «чёрный ящик». Мы рассылаем резюме, проходим созвоны, получаем странные вопросы и туманные отказы. Что на самом деле происходит в голове у рекрутера? Почему один и тот же ответ где-то вызывает восторг, а где-то — вежливое «мы вам перезвоним»?

Чтобы пролить свет на этот процесс, мы разобрали более 10 часов записей живых, нефильтрованных эфиров с QA-практиками. В роли наших проводников выступят:

Lead QA Ада Ширченко (7+ лет в QA), Senior QA Юлия Самусева (8+ лет в QA) и Middle+ QA Евгений Гусинец (3+ лет в QA)

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

Мы не нашли свежего исследования про QA и решили: нужно делать своё. Так появилось наше первое большое огромное исследование про QA в России.

 Что внутри?

— Как работают в QA: какие процессы, инструменты и подходы используют.

— Зачем тестировщики работают: мотивация, удовлетворённость сферой и зарплатой.

— Будущее QA: как инженеры видят развитие профессии и какую роль в этом сыграет AI.  

Приправили статистику комментариями ребят из сообщества. 

Под катом собрали несколько важных инсайтов. С полной версией исследования можно ознакомиться по ссылке: https://qa-survey-2025.2gis.ru

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

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

Приветствую читателей моей статьи!

В тестировании я уже 8 лет. Начала тогда, когда это еще не было мейнстримом :-)

Однако, сегодня эта профессия стала очень популярной и, по слухам, новичкам практически невозможно начать карьеру в этом поприще. Многие ребята сталкиваются с проблемой «донести» свое резюме до компании и попасть на собеседование. Поэтому я решилась на эксперимент и опубликовала резюме новичка без опыта работы на hh.ru, чтобы посмотреть – получится ли получить обратную связь.

Итак, входные данные.

Я взяла реальную историю и описала свои знания и навыки 15 летней давности т.е. на момент выпуска из колледжа.

Хабр, привет! На связи Александр Леонов из Экспертного центра безопасности Positive Technologies (PT Expert Security Center), дежурный по самым опасным уязвимостям месяца. Мы с командой аналитиков Positive Technologies каждый месяц исследуем информацию об уязвимостях из баз и бюллетеней безопасности вендоров, социальных сетей, блогов, телеграм-каналов, баз эксплойтов, публичных репозиториев кода и выявляем во всем этом многообразии сведений трендовые уязвимости. Это те уязвимости, которые либо уже эксплуатируются вживую, либо будут эксплуатироваться в ближайшее время.

С прошлого дайджеста мы добавили 3 трендовые уязвимости.

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

Меня зовут Даниил Ахетов. Я занимаюсь автоматизацией тестирования уже достаточно давно. В основном пишу на JavaScript. Внедрял инструменты автоматизации тестирования в Яндексе, строил целое направление автоматизации тестирования фронта в SberDevices, но какие бы фреймворки я ни использовал и какие бы команды ни собирал, я всегда сталкивался с одной и той же проблемой: автоматизация тестирования не успевает. Мы постоянно работаем в догоняющем режиме. Причин этому много, но я для себя выделил три основные.

Использование ИИ в работе - одна из самых обсуждаемых тем последнего года. Моя жена активно применяет его в своих задачах, и когда мы что-то обсуждаем, она удивлённо спрашивает: «А ты-то почему до сих пор не используешь ИИ?» И в какой-то момент я и сам задумался - а правда, почему?

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