Тестировщик с 50-летним стажем Александр Александров рассказывает про количественное управление процессом тестирования: какие метрики в ИТ-проектах бывают, как можно спрогнозировать количество дефектов в коде и зачем вообще оценивать результаты тестирования по численным KPI.
Привет, Хаброжители!
В предыдущих статьях мы изучили подходы к разведке и анализу целей, а также ключевые аспекты этапа сканирования. Теперь пришло время разобраться в анализе парольных политик, ACL и DNS, найти способы бокового перемещения и провести обзор основных актуальных техник повышения привилегий.
Этот этап анализа безопасности — ключевой для оценки того, насколько эффективно корпоративная сеть защищена от различных угроз. Расскажу, из каких действий он складывается и какие инструменты нужны для их реализации.
В этой статье вас ждет база — те вещи, которые должен знать каждый начинающий пентестер, занимающийся аудитами внутренней инфраструктуры.
Привет. Это статья-туториал про выбор технологии и реализацию проекта нагрузочных тестов для API REST микросервисов. Про себя и специфику продукта, над которым работаю, я подробно описывал тут, когда рассказывал о интеграционных тестах. Здесь этому уделять внимание не буду. Если решитесь продолжать, то Вас ждет длинное чтиво. Результатом потраченного времени и внимания будет понимание того, зачем нужно нагрузочное тестирование, с чего начать, куда двигаться дальше и шаблонный проект нагрузочных тестов, который Вы сможете адаптировать под себя. Все используемые мной технологии в этой статье несут печать Java экосистемы. Это тоже может повлиять на то, решитесь ли Вы продолжать. Поехали ...
Это вторая книга из трилогии Ольги Назиной по тестированию ПО. Про первую книгу автор рассказала в своем блоге на Хабре, третью мы осветили в предыдущем посте. Мультяшный авторский стиль изложения с сотнями картинок-комиксов необычен для компьютерной литературы, но почему бы и нет? Книга легка в восприятии и помогает грамотно использовать техники проектирования тестов, знакомит с границами их применимости.
Собираясь писать UI-тесты для приложения на Compose Multiplatform, я столкнулась с дефицитом туториалов и документации по этой теме. Из полезного были только пара статей (https://habr.com/ru/articles/674112/) и выступлений на недавних конференциях, а примеры в основном сводились к щелчку по кнопке и проверке результата. Пришлось писать почти наугад, запуская код и изучая результат. Хочу поделиться с Хабром получившимися наработками.
Привет, Хабр!
Меня зовут Тоня. В SM Lab я работаю старшим инженером по обеспечению качества в команде продукта Интра — занимаюсь ручным тестированием и написанием автотестов на Kotlin. В этой небольшой статье хочу рассказать, как я искала работу и проходила собеседования через One Day Offer. Под катом — муки выбора инструмента для поиска работы, этапы прохождения собеседования за один день, трудности, с которыми столкнулась, и причины, по которым выбрала SM Lab и не прогадала.
Шаг первый: где сейчас искать работу
Привет, Хабр! Всем известно, что у тестировщиков в жизни много трудностей. И мы, команда QA Департамента общих прикладных сервисов (ДОПС) Сбера, знаем об этом не понаслышке, так как тестируем релизы сервисов Platform V — цифровой облачной платформы СберТеха (более 70 продуктов для быстрого создания и легкого масштабирования приложений любой сложности). Да‑да, именно на Platform V Сбер совершил свою цифровую трансформацию!
Релизы поставляют в банк из СберТеха. Всё бы ничего, пришли изменения — тестируй. Но основная сложность заключается в том, что у платформы десятки продуктов, из‑за чего работа усложняется в разы.
Всем привет! На связи Наталья Данилина и Иван Чечиков из Звука. В этой статье мы хотим поделиться опытом внедрения snapshot-тестов для web-приложения — расскажем, что это такое и для каких задач применяется.
Подробности – под катом.
На протяжении истории люди придумывали различные подходы и приёмы, как разрабатывать более качественные и поддерживаемые приложения. В этой статье я бы хотел рассказать о такой методологии разработки, как BDD (Behaviour Driven Development). Но прежде чем перейти непосредственно к гвоздю программы — небольшое вступление.
Думаю, большинство разработчиков согласятся с мыслью о том, что покрытый юнит-тестами код лучше, чем непокрытый. Действительно, тесты позволяют эффективно следить за работоспособностью кода, вовремя отлавливать нерабочие изменения. А ещё из наличия юнитов обычно следует то, что код разбит на логические модули и каждый класс/функция имеет одну зону ответственности (привет SOLID). Тот, кому доводилось писать тест на большую функцию с несколькими зонами ответственности знает, что тесты на такую функцию обречены быть хрупкими и падать при малейшем изменении. Это заставляет задуматься о том, чтобы не писать всё "в одной портянке", а писать гибкий код поделённый на модули. С таким кодом, как правило, приятнее работать, т.к. приходится держать в уме меньше информации.
В какой-то момент люди сделали вывод, что раз код хороший если он тестируемый, тогда давайте мы сначала напишем тесты на этот код, а уже потом сам код. И так придумали методологию...
Мой первый опыт на Хабре получился не очень положительным, и, признаюсь, до сих пор смотря на комментарии и оценки, мне стыдно и больно где-то внутри.
Потому в имя исправления ошибок молодости решил написать серию статей о том, как дома собрать свою "идеальную" хранилку, или сервак, или мини облако. Поделюсь опытом, своими знаниями и пониманием, а также мыслями, которые могут помочь выполняя похожую задачу для себя.
Немного предыстории: я начала свой путь в QA в частности (и в IT в целом) 7 лет назад, когда "войти в IT" было не так мейнстримно, как сейчас. Курсы, если и были, то не на слуху. Чтобы устроиться QA Junior, я самостоятельно выискивала информацию в интернете, готовясь к собеседованию. Не помню как (видимо, память вытеснила травматичные воспоминания :) ), но собеседование я прошла и приступила к началу тестерской работы.
К чему я это всё?
Системное тестирование - это этап тестирования программного обеспечения, на котором тестируется полный и полностью интегрированный программный продукт на основе спецификации программного обеспечения (SRS: Software Requirement Specification). Основная цель такого тестирования — это процесс оценки, который охватывает аспекты, связанные с бизнесом, функциональной спецификой и потребительскими ожиданиями.
Награда за обнаружение багов разного уровня зависит от сектора и типа уязвимости. Активнее всего с программами Bug Bounty работают IT-компании, онлайн-сервисы, сфера услуг, торговля, финансовые организации и блокчейн-проекты. Средняя сумма вознаграждения может составить:
критический уровень опасности — $40 000;
высокий уровень опасности — $20 000;
средний уровень опасности — $5000;
низкий уровень опасности — $0.
В одной из статей мы уже писали, что Bug Bounty — это не разовая услуга, которую можно приобрести и забыть, как в случае с пентестом. Компании должны понимать, что внедрение, поддержка и развитие этой практики обойдутся им недешево. Так, средняя стоимость годовой подписки на услуги платформ Bug Bounty начинается с $16 000 за рубежом и стартует с 600 000 ₽/год в России.
Мы решили поговорить с Лукой Сафоновым, чтобы узнать, могут ли компании сэкономить на Bug Bounty, и не потерять в эффективности программ. Вот, что из этого получилось.
Ольга Назина — признанный автор книг и учебных курсов по тестированию ПО. Удивительный мультяшный стиль изложения с сотнями картинок‑комиксов помогает легко воспринимать сложные темы, постигать азы и развиваться в профессии специалиста по QA. Новая книга, вышедшая в 2024 году, знакомит с тонкостями регистрации и отслеживания статуса багов в процессе разработки приложений. Будет безусловно полезна начинающим тестерам, слушателям ИТ‑курсов, а также всем, кто интересуется системным подходом к тестированию ПО.
Однажды мне попалась на глаза статья про сотрудника, который реализовал в Excel книге полноценную игру с интерфейсом, противниками и другими механиками. Продолжив изучать эту тему, я увидел целый мир, в котором люди, используя не предназначенные для этого продукты, реализуют различные игровые механики. Эта мысль попала мне в голову, и после этого мне всегда хотелось самому реализовать нечто подобное.
Новая линейка процессоров Intel Core 14-й серии, вышедшая в прошлом году, наделала много шума в первую очередь из-за своей неоднозначности. С одной стороны, она получила очередной поколенческий номер, который должен был стать последним в модельном ряду. При таком раскладе завершать аккорд логичнее всего было бы на высокой ноте. С другой, новые процессоры, как и поколение до них, отнесли к семейству Raptor Lake с припиской Refresh, указывающей на обновление, что совершенно не располагает к знаковому апгрейду. Так что же получилось на самом деле?
С предыдущего поколения Intel провел хоть и неравномерную, но все-таки заметную работу по улучшению новых процессоров К-линейки, которые строятся во многом на одних и тех же принципах, что и их предшественники. Например, даже Intel Core i5-14600K использует один и тот же кристалл, что и в старших версиях с идентичной площадью и количеством ядер, часть из которых, в базовой модификации просто заблокирована.
Номинально многие характеристики новых процессоров остались без изменений со времен 13-го поколения. Но, если копнуть чуть глубже, начинаешь понимать, что преобразования есть. Кое-где подросла тактовая частота, кэш L2/L3, а где-то даже нарастили количество ядер и потоков.
Все три процессора нового поколения получили дискретную поддержку Wi-Fi 7, о котором мы уже рассказывали. В статье разобраны основные отличия нового стандарта от всех предыдущих, а также уточняется, какую точку доступа следует выбрать, чтобы реализовать весь его потенциал.
Разработка контроллера для аппарата искусственной вентиляции легких
Мы рады представить вам нашу очередную статью из цикла статей «Моделирование руками и глазами студента», посвященную разработке контроллера для аппарата искусственной вентиляции лёгких, выполненную в программном обеспечении REPEAT. Автором этой работы является студентка РГУ имени Косыгина Ульяна, которую мы благодарим за ее усердие и талант.
В статье подробно описана математическая модель и результаты моделирования, которые показывают, насколько эффективно программное обеспечение REPEAT может быть использовано в области медицинской техники.
Ссылка на телеграм-канал REPEAT: https://t.me/repeatlab
Существуют различные способы аутентификации в системах Windows, каждый из этих способов сохраняет или кэширует переданные учетные данные. В этом модуле мы рассмотрим основные типы аутентификации и места кэширования переданных данных, а также разберем, как можно получить к ним доступ.
Локатор — обязательный элемент любого автотеста, который позволяет системе находить правильный путь к тестируемому компоненту интерфейса. От точности локатора и корректности его оформления зависит не только, смогут ли разобраться с локатором тестировщики и другие коллеги, но и сможет ли в целом автотест безошибочно найти искомый компонент среди множества на странице для выполнения целевой проверки.
Меня зовут Елена Пранова. Я инженер по автоматизации тестирования в ОК. В этой статье я хочу рассказать о том, как мы работаем с локаторами для автотестов: каких принципов придерживаемся, чего стараемся избегать и какие правила выработали на своем опыте.
