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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для автоматизации тестирования веб‑приложений существует множество инструментов. Они помогают разработчикам и тестировщикам повысить эффективность своей работы и снизить рутину. Сегодня рассмотрим два популярных фреймворка: Selenium и Playwright. Взвесим все плюсы и минусы, а вывод вы сделаете сами. Всем привет. Меня зовут Никита. Я работаю разработчиком в «Совкомбанк Технологии». Решил поделиться своим мнением о фреймворках Selenium и Playwright. Оговорюсь сразу. Данная статья носит исключительно образовательный характер, не ставит своей целью рекламу и не являются частью коммерческих продуктов компании. Ну, как вы понимаете, нет мне никакого смысла рекламировать тот или иной фреймворк. Поехали!

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

Привет, Хабр! Меня зовут Давид, еще недавно я был стажером YADRO, а сейчас работаю в отделе разработки ПО поддержки сетевой аппаратной части. У нас в команде есть большой проект на более 100 000 строк, написан на C++ (и частично на С). Код переписывался много раз, а за самим проектом на правах легаси особо никто не следил: работает — не трогай. Когда я пришел в команду, у меня была задача: привести код в порядок и отловить ошибки, которые пропускает компилятор — например, возможное разыменование нулевого указателя, неинициализированные переменные или простые опечатки. 

Одним из очевидных решений было использование статического анализатора. Выбрали довольно известное коммерческое решение, но долгие прогоны не привели ни к чему дельному. Решили поэкспериментировать с другими вариантами статических анализаторов, сделав ставку на open source. Поиски привели к инфраструктуре CodeCheсker, которая предоставляет удобный интерфейс запуска и настройки статических анализаторов через аргументы командной строки. С помощью инструмента удалось достичь результатов, которые значительно превысили значения, полученные на коммерческом решении.  

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

Привет! Меня зовут Алексей Колесников, я работаю в отделе обнаружения вредоносного ПО экспертного центра безопасности Positive Technologies (PT Expert Security Center, PT ESC), в команде PT Sandbox.

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

Всем привет! Нагрузочные тесты за 5 минут (ну почти).

Не так давно делился историей о том, как решали проблему E2E автотестов в маленьком проекте. Продолжим историю).

Когда фича «протестировать табуретку» вызывает нервный смех у тестировщиков и недоумение у менеджеров, пора разобраться, как на самом деле работает тестирование. Привет, Хабр. Меня зовут Елизавета Лященко, я работаю тестировщиком 5 лет, из которых 1.5 года в Самолете, и сегодня разложу по полочкам весь цикл проверки — от странных требований до стресс-тестов и финального релиза. Мы узнаем, почему тестировщик задает миллион вопросов, чем его работа отличается от «я всё проверил, всё ок» и как тестирование спасает команду от хаоса. Ну и готовьтесь увидеть табуретку так, как вы ещё никогда её не видели!

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

Разработка через тестирование (TDD) — это отличный метод, который позволяет быстро получать обратную связь по идеям дизайна и реализации, а также быстрее прийти к работающему решению.

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

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

Всем привет! Меня зовут Александр Наумов, я работаю в IT больше 12 лет, из которых последние несколько лет занимаюсь тестированием. В SM Lab я курирую тестирование в продуктовых командах. Вообще, я адепт продуктового подхода — люблю, когда команды деплоят ценности продукта в продакшн, а не просто делают задачи.

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

Сегодня расскажу про самые опасные уязвимости августа. Всего их было шесть, и большая их часть была обнаружена (surprise!) в продуктах Microsoft. В каких – рассказываю под катом.