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

Привет, Хабр! Меня зовут Марина, я QA-инженер в Купере. Как специалисту по тестированию, мне часто приходится сталкиваться с задачами, связанными с тестированием микросервисов, использующих асинхронное общение через Apache Kafka. Уверена, многие QA-инженеры, да и разработчики знакомы с подобными вызовами.

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

Консольная утилита Protokaf не имеет интерфейса и полученные данные для лучшей читаемости нужно отформатировать в json структуру (а это еще одно доп приложение).

UI-приложение Kowl удобно только для мониторинга состояния топиков, и только недавно в нём стала доступна возможность чтения сообщений без сложного флоу для расшифровки, но всё так же нет возможность отправки сообщений в топик. 

В поисках более удобного решения коллега посоветовал Plumber — графическое приложение, с возможностью коньюмера и продюсера сообщения.

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

Привет, Хабр! Меня зовут Дмитрий Королёв, я инженер по нагрузочному тестированию Platform V Pangolin — целевой СУБД в Сбере и не только. Эту статью я написал вместе с моим коллегой Алексеем Хорохориным @AlexeyHorohorin. Наш продукт — специальная сборка PostgreSQL с доработками (крупных больше 30, а всего уже больше 70) в области безопасности, производительности, отказоустойчивости.

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

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

Есть мнение, что в силу особенностей вебсокетов, WAF не может их нормально анализировать и защищать. Давайте попробуем разобраться, насколько это утверждение справедливо.

В предыдущей части статьи мы рассмотрели общие подходы к тестированию PDF и познакомились с тем, как библиотеки pdfminer и PDFQuery помогают нам получать детальную информацию об объектах. Достаточно ли нам этой информации? Далеко не всегда. В этой статье мы расскажем о решении некоторых интересных технических проблем.

Почти четыре года я познаю дивный мир тестирования в департаменте корпоративных систем ЛАНИТ. Последние полтора ― на финтехпроектах, поэтому работа с логами стала частью моего рабочего процесса. В этом гайде я познакомлю вас с ключевыми моментами, которые помогут понять логи лучше и применять инструменты логирования эффективнее.

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

Секреты айтишной карьеры, о которых лучше не рассказывать...

...но которыми всё же с нами поделился QA lead "ITQ Group" Сергей Мурашов.

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

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

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

Всем привет! Меня зовут Лысенко Алексей, я тестировщик бэк-офисного программного обеспечения в РСХБ-Интех – дочерней ИТ-компании РСХБ.

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

Иногда до начала эксперимента не удаётся оценить то, какого размера должна быть выборка, способная обеспечить его нормальное проведение. Для решения этой проблемы можно провести последовательный тест или A/A‑тест. Но последовательные тесты обычно отличаются меньшей чувствительностью и оказывают отклоняющее влияние на статистическую оценку эффекта воздействия. A/A‑тесты увеличивают длительность экспериментов, не гарантируя при этом того, что найденный в итоге размер выборки окажется корректным. В этом материале мы представим основные моменты из нашей недавней публикации (Precision‑based designs for sequential randomized experiments, Mattias Nordin, Mårten Schultzberg, 2024), в которой мы представляем альтернативный метод, названный нами «fixed‑power design» (схема эксперимента с фиксированной статистической мощностью). При применении схем с фиксированной статистической мощностью эксперимент начинают, не имея оценки размера выборки. Необходимый размер выборки находят, опираясь на имеющиеся данные о текущих результатах эксперимента. Эксперимент останавливают в тот момент, когда текущий размер выборки оказывается больше необходимого размера выборки. Мы покажем, что эксперименты с фиксированной статистической мощностью можно анализировать, используя стандартные методы без какой‑либо коррекции. Точечные оценки оказываются непротиворечивыми, а доверительные интервалы эффекта воздействия обладают асимптотическим номинальным покрытием. Не все формы «подглядывания» приводят к увеличению частоты появления ложноположительных выводов на основе выборки фиксированного размера.

Нет, это не очередной обзор зарплат по вакансиям.

Наоборот, по результатам прямого опроса QA-специалистов поговорим про шесть причин того, почему аналитика по вакансиям не очень релевантна настоящей ситуации с зарплатами на рынке (которые на самом деле выше).

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

Привет! Меня зовут Юрий, я старший разработчик в Купере в команде Ruby Platform, занимающейся разработкой внутренних библиотек, инструментов мониторинга и поддержки микросервисов.

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

Из данной статьи вы узнаете:

- общий принцип работы контрактных тестов;

- о проблемах, с которыми мы столкнулись при внедрении контрактного тестирования и как их решали;

- как мы разработали свое решение для контрактного тестирования Ruby-приложений;

- о настройке CI/CD для автоматизации контрактных тестов.

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

Привет, Хабр! Я — Ольга Султанова, руководитель тестирования в Рунити. Сегодня я расскажу о QA-метриках, которые мы применяем в работе: как мы их внедряли, как собираем данные, как автоматизируем и анализируем. А также о том, какие у нас стоят пороговые значения и о том, какие действия мы предпринимаем, когда они нарушаются.

Зачастую full stack (и не только) проекты создаются без функциональных тестов.

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

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

Проблема сложности тестов в подобной ситуации кроется в том, что на этапе проектирования продукта никто не думал о его тестировании и необходимости сделать его пригодным для тестирования (автоматического).

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

В этой части статьи я на примере покажу, как можно спроектировать простое веб-приложение, используя функциональное тестирование, и имплементировать веб-приложение.

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

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

В прошлом непрерывное интеграционное тестирование было с нами не всегда, в отличие от обычного тестирования. По моим наблюдениям, CI — это результат того, что тестирование всё больше ускоряется. Разберёмся, как это произошло и как тестирование будет ускоряться дальше.

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

Обсудим три базовых подхода к тестированию чего‑либо в программе:

В Lamoda Tech более 50 QA backend-инженеров стоят на страже качества нашего продукта. Мы тестируем более 200 систем на Go, PHP и Java и постоянно работаем над процессами тестирования.

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

Если вы хотите пощупать GraphQL API с ТЗ на русском языке, то добро пожаловать в мою песочницу — систему Cards.

Тут есть пользователи и их банковские карты. Можно пополнить баланс банковской карты, можно переводить деньги с одной карты на другую. Есть графический интерфейс и API. Есть даже ролевая модель! И даже ТЗ есть, хоть и не супер подробное =)

В данной статье хочу рассказать про инструмент измерения покрытия gRPC сервисов tests-coverage-tool, написанный на языке Golang. Основная задача инструмента — автоматическое измерение покрытия требований на основе proto контрактов. Поговорим про использование в автотестах, концепцию, отчет и кратко про архитектуру самого инструмента tests-coverage-tool.