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

Прошло 1,5 года с нашего последнего обзора балансировщиков, а кажется, будто мы попали в другой технологический мир. Цифровая трансформация дышит в спину, ИБ продолжает закручивать гайки, а новые вендоры пачками выходят на освободившуюся сцену. Все это — определяет развитие рынка ADC-решений, который повторяет классический цикл «отрицание → гнев → торг → депрессия → принятие». Судя по всему, мы где-то на середине пути — подробнее об этом расскажем в статье. 

В качестве испытуемого на этот раз рассмотрим китайского вендора DPTech, который достойно показал себя в нашей техлаборатории (хотя, безусловно, есть куда расти). Это один из немногих доступных производителей ADC, который обладает достаточной технической зрелостью, разрабатывает все самостоятельно — от FPGA чипов до ПО и предлагает решения как для физических, так и для виртуальных инфраструктур. 

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

Привет, меня зовут Андрей и я автоматизатор (остальные в кругу хлопают в знак сочувствия) в hh.ru. В статье расскажу, как мы ввели карантин автотестов, повысив стабильность релизов и скорость доставки.

Привет, Хабр!

Сегодня рассмотрим, как тестировать React‑хуки с помощью @testing-library/react-hooks.

Запуск любого производства, будь то сервера для дата-центра или бытовой электроники, строится на трёх ключевых столпах: техническая документация (ТД), тестовая оснастка (ТО) и тестовое программное обеспечение (ТПО). Эти три элемента — основа реализации массового производства: от первого прототипа до серийной партии. Но довести их до совершенства практически невозможно. Всегда можно сделать что-то лучше: добавить новые функции в ПО, сделать новый чертёж в ТД или улучшить функциональность тестовых стендов. Однако жесткие сроки, бюджеты и нехватка ресурсов заставляют выбирать, где быть идеалистом, а где — прагматиком.

В статье мы рассмотрим, как находить этот компромисс между теорией и практикой. Мы обсудим подходы к созданию ТД и ТПО, поймем, как конфликты между инженерами и управленцами влияют на производственный цикл, и разберем ситуацию, когда важно остановить разработку вовремя, даже если задача выглядит всё ещё "недоделанной". Эта статья адресована инженерам, технологам, проектировщикам, а также менеджерам, которые хотят глубже понять сложный процесс превращения технических идей в реально работающие продукты.

Привет, хабровчане. В этом дайджесте делимся подборкой открытых уроков, которые проведут преподаватели OTUS в рамках набора на онлайн-курсы в июле. В программе — от глубоких погружений в архитектуру DWH и сетевые протоколы до навыков работы с ML-моделями и DevOps. Каждый урок — возможность разобраться в ключевых аспектах IT-сферы, задать вопросы экспертам и закрыть пробелы в знаниях.

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

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

В текущих реалиях тестировщики часто остаются в тисках рутины: трудозатраты на создание тест-кейсов и их ручной импорт в TMS (системы управления тестированием) съедают до 40-60% рабочего времени QA-инженера (по данным World Quality Report). Это не просто неэффективно, это тормозит весь релизный цикл.

Но что, если рутину можно переложить на ИИ, не ломая процессы? Представьте: вместо часов кропотливой работы — готовые тест-кейсы за минуты, сразу загруженные в вашу TMS (Allure, Zephyr, TestLink, Test IT и др.) без танцев с авторизациями, VPN и десятками открытых вкладок. Звучит как фантастика? Это уже реальность, и работает она там, где вы бываете каждый день, в Telegram.

Таким образом, получим взрывной дуэт: Telegram-бот + GPT на службе QA.

Данное решение — Telegram-бот, который использует мощь GPT для мгновенной генерации структурированных тест-кейсов по вашему ТЗ (User Story, спецификация, даже голосовое сообщение!). Но главная магия — прямая интеграция с вашей TMS.

Аз есмь

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

Планирование спринта часто напоминает стрельбу из лука с закрытыми глазами: мы надеемся попасть в цель, но попадаем себе в колено (конец приключениям). Срыв сроков крайне редко происходит из-за лени или некомпетентности — чаще всего виноваты неучтённые риски.

Всем привет! Продолжаем погружение в ИТ-инфраструктуру глазами хакера. В предыдущей статье мы рассказали про процесс создания графа моделирования киберугроз – цифровой модели инфраструктуры, которая учитывает потенциальные действия злоумышленников, и про алгоритмы, которые рассчитывают возможные маршруты перемещения атакующих внутри системы. 

Следующий шаг – это оценка опасности найденных маршрутов. В этом случае, метрика времени атаки – это один из ключевых параметров анализа. Чем меньше времени потенциально требуется для реализации атаки, тем больше вероятность, что средства защиты и ИБ-специалисты не смогут вовремя обнаружить злоумышленника и остановить взлом. Что же нам даёт метрика времени?

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

Документация есть, тесты написаны, проверки закончили, даже QA не выгоревший. И всё равно за день до выкладки что-то ломается. Мы собрали истории — из больших и не очень команд — о том, как баги всплывают в последний момент и что с этим делать, если вы не Google, а просто хотите выкатиться без боли.

В технологических компаниях A/B‑тестирование давно стало основой для принятия решений, основанных на данных. Меня зовут Диля Хакимова, я работаю в команде платформы экспериментов Laba в Яндекс Go, и мы с командой помогаем руководителям и аналитикам быстро получать ценную информацию с помощью A/B‑тестирования.

Мы занимаемся разработкой методологии и помогаем специалистам решать вопросы, связанные с экспериментами и статистическим анализом. За время работы мы заметили: вокруг A/B‑тестирования до сих пор существует множество заблуждений.

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

В этой статье мы разберём 10 распространённых мифов об A/B‑тестировании, поможем разобраться в теме глубже и сделать ваши эксперименты эффективнее.

Дело было в Питере ― я шел по брусчатке и оступился. Чтобы сохранить лицо, я пожертвовал руками. Ну и как теперь жить и работать? ― спросите вы. Рассказываю. Спойлер: больничный я не брал.

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

Позвольте провести вас по пути создания инструмента для тест-драйва, который превращает теорию в живой опыт: отвечает на поставленные выше вопросы, создает индивидуальную среду с мгновенным стартом, где нет никаких сложных подготовок. На стенде вы полностью управляете процессом, тестируете функции в своем ритме, «прикасаетесь» к технологиям: запускаете сценарии, имитируете атаки, анализируете результат и сразу видите, как продукт решает ваши задачи.

Привет! Меня зовут Алексей, я работаю тестировщиком в компании «Совкомбанк Технологии». Хочу поговорить о нефункциональном тестировании мобильных приложений на платформах Android и iOS.

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

Привет, Хабр. На связи Даниил Кобылкин (@danilkkk) и Тимофей Тимошевский (@timhok17). Мы фронтенд-разработчики в Одноклассниках.

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

Рассказываем в статье, какие инструменты и подходы для генерации юнит‑тестов существуют, и как мы научились генерировать юнит‑тесты в своем проекте.

В мире технологий есть один необычный момент, который навсегда остался в истории — мотылёк стал частью истории вычислительной техники. Слово «баг» использовалось для обозначения сбоев в работе машин и до этого, но 9 сентября 1947 года это слово приобрело совершенно новый смысл.

Привет, Хабр! Я Ксения Сергеева и сегодня расскажу свою историю, как я оказалась докладчиком на конференции SQA days 36 и (спойлер!) внезапно заняла со своим докладом 3 место среди 56 докладов конференции.