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

Привет! Меня зовут Бальцер Вадим, я QA-инженер в команде android направления Банки.ру. Сегодня поделюсь нашим опытом внедрения автотестов обратной совместимости и интеграции их в CI. 

В материале расскажу: 
1) зачем нашей команде понадобились автотесты для контроля обратной совместимости API, почему мы выбрали Postman CI.
2) с чего начали: базовые вещи + полезные советы для начинающих.
3) есть ли жизнь за гранью проверок схемы.
4) CI и интеграция с ТестОпс.
5) к чему пришли и какие перспективы видим.

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

Привет, Хабр! Если вы это читаете — значит, вы интересуетесь кибербитвой Standoff. Эта статья первая из цикла, цель которого познакомить с платформой всех, кто мечтает поучаствовать в кибербитве впервые. Интересно будет и матерым игрокам — ведь даже самая незначительная крупица опыта коллеги может стать неоспоримым преимуществом во время кибербитвы.

На связи Антипина Александра (N3m351d4) aka капитан команды Cult. Если ваш опыт не похож на наш, мы всем комьюнити будем рады узнать, как участвует в Standoff ваша команда. Ждем ваши истории в комментариях 😊

Привет, Хабр! Я являюсь тестировщиком компании TravelLine. Мы разрабатываем единую систему для гостиничного предприятия, которая помогает отелям, санаториям и другим средствам размещения автоматизировать бизнес-процессы.

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

Привет! Я Александр Зырянов, проектный менеджер TestY и QA-менеджер в департаменте контроля качества YADRO. Тест-менеджмент системе TestY, которая доступна в open source любой команде и компании, скоро два года. Мы готовим крупный релиз 2.0 с масштабными изменениями, в том числе дизайна интерфейса.

А пока в качестве «аппетайзера» я расскажу про последние обновления к релизу 1.3.4. Среди них — bulk-операции, пуш-уведомления пользователей, доработка кастомных атрибутов и статусов. Подробнее о каждом — под катом. Устанавливайте TestY и испытайте в работе нашу открытую систему. 

Всем привет, меня зовут Андрей Федотов, я бэкенд-разработчик в компании «Цифровая Индустриальная Платформа».

Как сказал Кент Бек: «Многие силы мешают нам получить чистый код, а иногда не удается даже получить код, который просто работает». В данной статье я расскажу историю нашего проекта с точки зрения тестов. О том, как мы получили если не чистый, то работающий код, который позволяет нашей системе быть устойчивее и устойчивее, надежнее и надежнее. О том, как у себя на проекте мы уничтожили старые скрижали, называемые тестами, и написали новые с нуля. И, конечно, покажу примеры и затрону теорию.

Привет, Хабр! Меня зовут Марина, я 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 (и не только) проекты создаются без функциональных тестов.

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

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

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

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

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

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