Ежегодно Pentestit выпускает уникальные лаборатории тестирования на проникновения. По своей сути, Test lab являются реальными копиями корпоративных сетей, которые содержат различные ошибки конфигураций. Каждый желающий может попробовать свои силы на практике совершенно бесплатно. Лаборатории разрабатываются с учетом наиболее распространенных уязвимостей. В Test lab используются различные сетевые сервисы (Mail, DNS, AD, VPN, WAF, и т.д), веб-приложения, API и прикладные программы, а также дополнительные вспомогательные элементы инфраструктуры для придания реалистичности.
В статье мы вспомним, какие задания встречались в предыдущей лаборатории и поможем подготовиться к новой Test lab 15.
Здравствуйте! Сегодня хочу рассказать о нашем опыте тестирования скриншотами с использованием python, selenium, и Pillow.
Зачем? У нас был довольно большой (~1000) набор тестов на стеке python, pytest, selenium, которые отлично проверяли, что кнопки кликаются, а статистика отправляется (с использованием browserup proxy), но пропускали баги типа таких:
Регулярные выражения (их еще называют regexp, или regex) — это механизм для поиска и замены текста. В строке, файле, нескольких файлах... Их используют разработчики в коде приложения, тестировщики в автотестах, да просто при работе в командной строке!
Чем это лучше простого поиска? Тем, что позволяет задать шаблон.
Например, на вход приходит дата рождения в формате ДД.ММ.ГГГГГ. Вам надо передать ее дальше, но уже в формате ГГГГ-ММ-ДД. Как это сделать с помощью простого поиска? Вы же не знаете заранее, какая именно дата будет.
JUnit и TestNG, несомненно, являются двумя наиболее популярными фреймворками для модульного тестирования (юнит-тестирования) в экосистеме Java. Хотя JUnit послужил вдохновением для TestNG, второй имеет ряд отличий и, в отличие от JUnit, работает для функционального и более высоких уровней тестирования.
В этой статье мы обсудим и сравним эти фреймворки, рассмотрев их функции и распространенные варианты использования.
Если вы работаете в IT, то о легаси вы слышите часто — обычно с множеством негативных коннотаций. Понятно, что это не «хороший код», но какой? Может старый, может не поддерживаемый или не обновляемый, а может просто чужой? Есть ли «полноценное» определение «легаси», на которое можно ссылаться? А когда разберемся — что нам делать с легаси? Попробуем разобраться.
Привет, меня зовут Вика Бегенчева, я QA-инженер в Redmadrobot. Я расскажу, как злоумышленники крадут наши данные, и что можно сделать, чтобы от этого защититься. Статья написана для начинающих тестировщиков безопасности и тех, кому непонятно, что за «фрукты» эти хакеры и чем они там занимаются.
Всем привет! Меня зовут Олег Сидоренков, и я отвечаю за IT-инфраструктуру в компании ДомКлик.
Ломать — не строить! Так обычно говорят люди, пытаясь показать деструктивный процесс простым, не требующим усилий. Сегодня я хочу вам рассказать о пользе Chaos Engineering (хаос-инженерия), зачем это нужно, и приведу несколько примеров из личного опыта.
Профессиональную сферу DWH (Data Warehouse, или, по-нашему, хранилище данных) отличает высокая технологичность, а также огромное многообразие используемых решений. Крупные компании строят хранилища с самыми разными инструментами и технологиями, отличаются архитектуры, процессы. Но необходимость идти в ногу со временем постоянно вносит свои коррективы.
Tinkoff.ru не исключение. Мы постоянно совершенствуем свои процессы и стремимся развивать не только внешние, но и внутренние продукты. И на примере хранилища данных я хочу рассказать о том, как эволюционировали наши процессы по обеспечению качества. В этой статье я расскажу о том, как ранее был устроен наш рабочий процесс, с какими проблемами мы столкнулись и какие события стали переломными в эволюции нашего процесса QA.
Продолжение цикла публикаций про автоматизацию функционального тестирования на Kotlin
с использованием фреймворка Kotest совместно с наиболее полезными дополнительными библиотеками, существенно облегчающими и ускоряющими создание тестов.
В этой части мы углубимся в возможности Kotest:
Все части руководства:
Когда разрабатывается новый функционал, аналитик пишет требования, а тестировщик их проверяет. До того, как начать реализацию. Потому что на этом этапе внести исправления дешевле всего.
Вот только на что обращать внимание при тестировании? Есть набор основных характеристик, которыми должна обладать хорошая документация:
Всем привет! Меня зовут Антон, я – инженер команды, отвечающей за развитие централизованных IT-сервисов, которыми пользуются продуктовые команды в X5 Retail Group.
В этой статье я расскажу о системах класса API Management и в частности о APIM Gravitee (https://www.gravitee.io), том, что это за класс систем, как они используются для обеспечения потребностей команд разработки. Статья не погружает в технические аспекты, но может быть полезна архитекторам и менеджерам, которые думают о том, чтобы попробовать использовать данный класс систем, но не знают, подойдут ли они для их задач, а также разработчикам, которые могут открыть для себя новые инструменты для удобной работы с API.
Дисклеймер: меня зовут Эрик Бурыгин, я давно работаю тестировщиком, веду студентов на курсе «Инженер по тестированию», поэтому может показаться, что тестировщик просто хочет перекинуть кусок работы на разработчиков. На самом деле у описываемого подхода есть как плюсы, так и минусы, поэтому статья носит в том числе и дискуссионный характер. Буду рад увидеть в комментах мнения как разработчиков, так и тестировщиков.
За пять лет работы в «Аркадии» — компании-разработчике программного обеспечения на заказ, где я работаю тестировщиком, — мне довелось поучаствовать в самых разных проектах. Большая часть из них была связана с веб-разработкой, меньшая — с мобильной. Некоторые проекты длились более года, другие были краткосрочными (полгода или даже пару месяцев). Менялся и размер команд: от трёх до трёх десятков человек.
Небольшие проекты у нас скорее редкость, и к ним не очень подходят стратегия и тактика тестирования, применяемые для длительных проектов. В этой статье я расскажу, как составляю стратегию тестирования в краткосрочных проектах и внедряю её на практике.
Уважаемые коллеги, всем доброго дня.
В данной статье хочу поделиться собственным опытом знакомства с MDM решением компании Юнидата (UniData). Попытаюсь сделать акцент на конкретные трудности и особенности платформы, с которыми столкнулся при переходе с SAP MDM на ЮниДата MDM.
Предыстория проекта
К моменту старта проекта по переходу на UniData MDM в Компании уже примерно 5 лет функционировала корпоративная система управления нормативно-справочной информацией (КСУ НСИ) на базе SAP MDM. Проект внедрения SAP MDM был по-настоящему успешным и эксплуатация системы практически не создавала проблем.
В КСУ НСИ велись два общекорпоративных справочника:
- материально-технических ресурсов, работ и услуг (МТРиУ), 200000 записей
- контрагентов, 40000 записей
Применялась модель централизованного ведения НСИ с единой точкой ввода через механизм заявок от пользователей. MDM выступал мастер-системой для ряда информационных систем Дочерних обществ, обслуживающих различные бизнес-процессы (бухгалтерский и налоговый учет, планирование и централизованные закупки, техническое обслуживание и ремонт оборудования и другие).
Конфигурация системы включала в себя портал (тонкий клиент, GUI) для работы с заявками пользователей, толстый клиент для настройки модели данных и других операций, специализированный инструментарий для экспорта и импорта данных и другие компоненты.
В системе была реализована достаточно сложная модель ведения данных, большой атрибутивный состав справочников. Система классификации и кодирования состояла из иерархических и фасетно-иерархических (онтологических) классификаторов и их связей (мэппинг), для записей было предусмотрено кодирование по системе свойств и значений, развит инструментарий в части управления качеством данных.
В целом состав данных и функционал системы можно назвать достаточно типовым для крупного бизнеса в сфере промышленного производства.
В силу разных причин перед Компанией встала задача импортозамещения системы SAP MDM с полным сохранением существующей функциональности.
Привет, Хабр! У клавиатуры снова я — Женя Пономаренко. Мы в «Кавычках» занимаемся тестированием и обеспечением качества для российских и зарубежных компаний. И мы — аутсорс агентство, т. е. тестируем проекты клиентов из разных сфер: от сложных — авиа и медицина, до ритейла и небольших стартапов. За свою карьеру в тестировании (а это ни много, ни мало — лет 15) я успел поработать в продуктовых командах, на фрилансе и в итоге стартанул агентство аутсорс тестирования. Пришел я к этому, потому что на одном проекте мне быстро становилось скучно, а аутсорс модель оказалась решением этой проблемы. Можно работать как компания со всеми корп. плюшками, по условиям ТК, но с разными проектами. А значит не сохнуть годами на одних и тех же задачах и непрерывно развиваться.
Я думаю, что многие, кто начинает карьеру в тестировании или те, кто уже в профессии, задаются вопросом «а куда идти-то?». Этого «куда» множество вариантов — открыл HH, «Хабр Карьера», телегу и еще стотысячмильенов площадок — выбирай не хочу. А вот где из всего этого многообразия не будет скучно, можно расти и зарабатывать? В этом вся соль и боль. Поэтому я решил написать обзор разных форматов работы для тестировщика. Возможно, кому-то это поможет понять, куда идти и зачем. А кому-то пересмотреть текущее место. Или кто-то вообще напишет, что это все фигня, и у него по-другому (кстати, добро пожаловать в комменты).
Как и многим, нам в Veeam нужны разработчики автотестов. Обычно на эту позицию претендуют специалисты с опытом в ручном тестировании ПО, но зачастую у них может не быть навыков программирования. А программисты, как правило, нечасто стремятся в разработку автотестов. Между тем у нас в компании есть автоматизаторы, которые изначально были не тестировщиками, а программистами, и они очень хорошо себя проявили в автоматизации. В статье я расскажу почему такой вариант развития карьеры может быть интересен для разработчиков.