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

Всем привет, меня зовут Антон Огольцов, я отвечаю за процессы тестирования в компании Integro Technologies. Мы являемся системным интегратором, представляющим услуги по разработке, внедрению и поддержке IT-решений для авиакомпаний, аэропортов и наземных служб. 

Сегодня предлагаю рассмотреть опыт использования инструмента TMS (Test Management System) – Test It. Мы проведем анализ функциональности, удобства использования и эффективности данного ПО. На Хабре много статей, описывающих использование Test IT для управления автоматизированным тестированием, наша цель – поделиться с читателями опытом использования TMS в части мануального тестирования.

Данную статью я разделил на две части. В первой мы сравним функциональность Test IT с ранее используемым Confluence и Jira для работы с тест-кейсами/тест-сьютами и фиксацией результатов тестирования. Во второй части рассмотрим использование общих шагов, пред- и постусловий секций и кейсов, а также ознакомимся с процессом создания тест-планов и ходом выполнения тестирования с последующим составлением отчета и аналитики по прохождению тест-планов.

Привет, Хабр! Меня зовут Александр Иоффе, в компании Aquarius я руковожу департаментом разработки средств автоматизации и обеспечения качества производимой продукции, такой как сервера, коммутаторы, ноутбуки, мониторы и так далее.

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

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

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

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

Обратите внимание: в этой статье речь идёт об отладчиках, работающих с нативным кодом – например, GDB, LLDB, Visual Studio C++. Отладчики для управляемых и скриптовых языков работают примерно так же, но могут отличаться детали реализации.

Привет, Хабр! На связи Денис Мурунов, руководитель практики построения ИТ-инфраструктуры К2Тех. Мне все больше кажется, что популярная последние два года тема изучения российских альтернатив западным решениям будет актуальна еще долгие годы. Столько статей на Хабре посвящают отечественным ИТ-продуктам, а запросов от рынка на подбор подходящего меньше не становится. Даже, наоборот, они кратно растут! 

В прошлой статье я рассказывал об отечественных службах каталога. А сегодня подготовил обзор на Зодиак АйТиЭм — систему управления ИТ-инфраструктурой. Она есть в реестре и, что важно, написана с нуля, а не базируется на популярном опенсорсе. Система управляет парками из разнообразных устройств, а скоро сможет устанавливать и сами операционные системы. Если есть задача перейти с Windows на Linux, Зодиак АйТиЭм может помочь облегчить этот процесс. 

Для этой статьи мы с командой решили протестировать Зодиак АйТиЭм на весьма непростой задаче — развертывание системы мониторинга сетей и серверов Glaber. Все подробности читайте под катом!

Техлид команды IMP Support в Авито Ангелина Архипова рассказывает, как автоматизировать рутинные процессы, облегчив тем самым жизнь QA-инженеров.

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

Мы — два сотрудника Ростелеком ИТ Алешин Алексей и Сердюк Нэлля. Наши проекты — большие порталы по видеонаблюдению на государственных мероприятиях (Единый день голосования, Единый государственный экзамен).

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

Современное приложение на Java с использованием Spring Boot, включающее множество клиентов (веб, десктоп, мобильные), может столкнуться с проблемами в тестировании по мере его роста. Даже при хорошем покрытии тестами (80%+), увеличение объема интеграционных и приемочных тестов может привести к значительным задержкам в процессе разработки. Тесты могут занимать до 24 часов для выполнения, что снижает эффективность и увеличивает риск багов в продакшене. Не знаю кто сказал, но вполне четко описывает процесс разработки

Что делать

... кроме написания резюме в поисках более интересно проекта?

Пробуем понять, где в авто тестах тормоза. И понимаем что все интеграционные и приемочные зависят либо от скорости тестера, либо от скорости отклика клиента во время авто-тестов. И то и то в сотни и тысячи раз медленнее вашего апи.

После анализа ситуации остается одно: как-то все это автоматизировать, причем быстро и дешево.

Ускорить тестировщика, без незаконных препаратов, мы не можем, как и сделать UI который будет работать без задержек, на скорости api (но можно постараться, но дорого...).

Основные шаги для решения:

Статей про эмоциональное выгорание много, и часть из них очень даже хорошие. Они фокусируются на работе с людьми: как и что говорить, какие ставить задачи, где вести общение, и вот это всё. Я хочу разобрать более узкую тему: специфичное выгорание тестировщиков. И решения буду предлагать не про людей, а про процессы. Как строить такие процессы разработки, чтобы минимизировать эмоциональное выгорание в команде? Какие баги (в коде и в процессе) надо фиксить? На какие штуки обращать внимание? Рассказывать буду с трёх позиций: что с каждой проблемой может сделать биг‑босс (РМ или собственник бизнеса), тест‑менеджер и сам выгоревший тестировщик. Букв в статье получилось много, сорян ))) Зато вроде полезные? Поехали!

Привет, Хабр! На связи лаборатория кибербезопасности AP Security и сегодня наши стажёры делятся своим важным профессиональным опытом.

Каждый, кто хотя бы немного знаком со сферой ИБ или краем уха слышал про Positive Hack Days, припоминает большие насыщенные киберучения под названием Standoff, на котором собираются лучшие хакеры, чтобы посостязаться в умении ломать инфраструктуру государства F. В противовес профессионалы синих команд упорно трудятся, разбирая реализованные киберинциденты . Под прицелом во время состязаний находится как внешний периметр, так и все то, что расположено за DMZ.

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

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

Привет! Я Екатерина Васильева, инженер-тестировщик ГК «Солар». В нашей работе есть извечный вопрос, как сделать тестирование быстрым, качественным и эффективным. И знаете, что помогает? Правильная организация процесса. В «Соларе», например, мы активно используем концепции DoR (Definition of Ready) и DoD (Definition of Done) при тестировании продуктов. Эти критерии, хоть и встречаются чаще в разработке, оказались невероятно полезны и для нас, тестировщиков. Они помогают четко понимать, когда задача готова к тестированию, а когда уже можно выдохнуть и сказать: «Готово!». В итоге — никаких срывов сроков и релизы день в день. В этой статье я расскажу на примере Solar webProxy, как DoD и DoR помогают нам повысить качество тестирования и с какими трудностями мы столкнулись, внедряя эти критерии.

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

Lettuce — это инструмент тестирования на Python, который предоставляет высокоуровневый API для написания тестов. Он предоставляет понятный и простой интерфейс API для тестирования с такими функциями, как автоматическое редактирование, шаблоны тестов и многое другое. Lettuce также построен на базе платформы Behavior Driven Development (BDD), которая помогает упростить разработку тестов, предоставляя клиентам общие утверждения BDD, такие как @given или @when.

Привет! Я Катя Глушанина, тестировщик в 2ГИС. В далёком 2019 год в нашей компании было не так много сотрудников, а тестировщиков в веб-отделе — ещё меньше. Мы все работали в офисе, много общались и решали вопросы на месте. Ламповость атмосферы была включена по умолчанию. Компания начала расти, и с этим пришли новые вызовы. Стало больше команд, тестировщиков, появились удалённые сотрудники.

Это привело к трём «побочным эффектам»:

Сложности коммуникации. У нас 11 часовых поясов, и это иногда тормозит доставку фич. Например, у меня возник вопрос, а тот, кто может с ним помочь ещё не начал работать или уже закончил.

Нет обмена знаний. В распределённых командах могут чаще придумываться велосипеды.

Чувство изоляции. Одному дома может быть грустно: даже мем не с кем обсудить.

И мы поняли, что нужно что-то менять.

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

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

Всем привет! Я Юлия Трусова, QA-инженер в Авито. Хочу рассказать вам про свой опыт проектирования и внедрения процесса работы с обращениями пользователей — SPT. Некоторые коллеги пытались расшифровать эту аббревиатуру как Support problem ticket, но это не аббревиатура вовсе. Это сокращенное название проекта SUPPORT в Jira, сгенерированное автоматически, где мы храним тикеты.

Всем привет! Меня зовут Павел, я технический лидер тестирования в направления мобильной разработки. В моей прошлой статье я описывал, как мы разворачивали тестовый стенд для тестирования Android на базе Selenoid, и почему выбор пал именно на этот инструмент.

Следующим этапом нужно было развернуть аналогичный стенд для UI-тестирования iOS.

Здесь хотел бы отметить, что готового решения под яблочные девайсы нет, как для Android, так и в документации по Selenoid нет информации для iOS. Поэтому я опирался на статью Selenoid: Запускаем Appium UI-тесты на iOS. Часть 2. Однако, у нас была другая история, мы поднимали стенд для UI-тестирования на реальных iPhone.

Всем привет! Меня зовут Роман Кабаев, я инженер в отделе разработки инструментов тестирования компании YADRO. Вместе с коллегами мы разрабатываем собственную тест-менеджмент систему с открытым исходным кодом TestY.

На этапе запуска TestY в качестве фреймворка для разработки мы выбрали Django, так как он позволяет в максимально короткие сроки реализовать MVP. Однако развивать такой продукт — добавлять фичи, наращивать число пользователей и объем хранимых данных в системе — бывает сложно.

Мы действительно быстро запустили MVP, перевезли данные из TestRail с помощью плагинов, и команды тестирования YADRO уже более года пользуются системой. Но есть одно «но»: пользовательские сценарии разных команд сильно отличаются. Так, добавление в систему более полумиллиона тестов привело к просадке скорости работы определенных эндпоинтов, завязанных на древовидных структурах. 

Спойлер: камнем преткновения для нас стали CPU-bound задачи с большим количеством данных, о том, как я это выяснил, расскажу ниже. Изучив, как можно ускорить выполнение таких задач в Python, я протестировал несколько решений и нашел оптимальное. Если вы разрабатываете веб-приложение на Django или Python и так же, как я, хотите ускорить работу сервиса, читайте эту статью.