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

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

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

Как измерить покрытие автотестами? Данный вопрос всегда вызывает жаркие дискуссии в рядах тестировщиков. Измерять покрытие становится сложнее, когда мы движемся вверх по пирамиде тестирования и уровень наших тестов растет. Как здорово на уровне Unit тестов, там отлично показывается сколько строк кода покрыто, процент и т.д. Вот если бы подобный отчет можно было сделать для end-to-end тестов или UI, то сразу было бы понятно реальное тестовое покрытие и каких тестов не хватает. К счастью, есть такой инструмент, который позволяет строить подробный отчет по покрытию Python сервисов.

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

Анализ некоторых уязвимых команд данного стека протоколов в статье, приятного чтения!

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