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

Компания у нас на full-remote, поэтому заседание кружка параноиков мы проводим как-то так. Иногда под банджо в углу.

В жизни любого проекта наступает катастрофа. Мы не можем заранее знать, что именно это будет - короткое замыкание в серверной, инженер, дропнувший центральную БД или нашествие бобров. Тем не менее, оно обязательно случится, причем по предельно идиотской причине.

Насчет бобров, я, кстати, не шутил. В Канаде они перегрызли кабель и оставили целый район Tumbler Ridge без оптоволоконной связи. Причем, животные, как мне кажется, делают все для того, чтобы внезапно лишить вас доступа к вашим ресурсам:

Макаки жуют провода. Цикады принимают кабели за ветки, и расковыривают их, чтобы отложить внутрь яйца. Акулы жуют трансатлантические кабели Google. А в топе источника проблем для крупной телекоммуникационной компании Level 3 Communications вообще были белки.

Короче, рано или поздно, кто-то обязательно что-то сломает, уронит, или зальет неверный конфиг в самый неподходящий момент. И вот тут появляется то, что отличает компании, которые успешно переживают фатальную аварию от тех, кто бегает кругами и пытается восстановить рассыпавшуюся инфраструктуру - DRP. Вот о том, как правильно написать Disaster Recovery Plan я сегодня вам и расскажу.

Автор: Надежда Дудник

Памятка для начинающих инженеров по тестированию ПО.

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

Все глаголы я как раз использовала на своих англоязычных проектах и указанные примеры я взяла из своих написанных тестовых сценариев и оформленных баг-репортов.

Данная информация собрана из нескольких постов в рамках моего блога, и я решила добавить всю эту информацию в пространстве habr.com.

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

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

Погружение в мир контейнеризации с докером — это путь к оптимизации развёртыванию приложений, а также ключ к упрощению жизни разработчиков и системных администраторов. Меня зовут Андрей Аверков, в IT c 2008 начинал пусть с аналитика-проектировщика IT систем, 11 лет в роли разработчика и последние годы на руководящих должностях. Сейчас я тимлид команды разработки из 9 человек в группе компании Кокос. Мы занимаемся созданием и поддержкой CPA платформ (gdeslon.ru, fxpartners.ru, ads.mobisharks.com), а также проектом по генерации лендингов — lpgenerator.ru. У нас большой опыт в разделении продуктов на части, поэтому, сегодня мы собрали самое основное и необходимое для работы с Docker. В нашей шпаргалке вы найдете все необходимое для успешного старта с докером: от базовых концепций и установки до продвинутых техник работы с контейнерами.

Привет! Меня зовут Никита Гуцалов, я инженер в компании YADRO и занимаюсь разработкой ПО для системы хранения данных TATLIN.UNIFIED. Вообще с системами хранения данных (СХД) я работаю уже много лет и люблю эту тему, поскольку она постоянно бросает новые вызовы, заставляя решать довольно сложные и нестандартные проблемы, что очень увлекательно само по себе, а удачные решения приносят огромное удовлетворение.


В статье я попытаюсь погрузить читателя в проблемы, с которыми нам, инженерам YADRO, приходится сталкиваться при отладке программного обеспечения СХД. Также покажу особенности работы с такими системами. Расскажу, какие инструменты, а иногда и решения, которые мы пишем сами, приходится для этого применять. А еще постараюсь сформулировать условия, которые необходимы для нахождения причин возникновения ошибок обработки данных в системе.

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

Салют, хабр! В интернете уже довольно много материалов о том, как другие команды строили свои решения для тестирования мобильных приложений (и не только), например: Яндекс Колхоз, Ферма мобильных устройств Selectel, Ферма девайсов VK, Ферма мобильных устройств в Сбере, Мобильная ферма 101 (доклад Антона Малинского).

Я же хочу рассказать про Ферму, которую мы строим в SberDevices. 

Меня зовут Александр Телешов, и я руковожу разработкой Фермы и Чембера (но про это расскажу в другой раз). Под катом вы найдете небольшую хронологию событий развития Фермы, собранные грабли, интересные факты и забавные наблюдения.

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

Привет, Хабр! Это Алексей Федулаев и Антон Жаболенко из Wildberries. Мы работаем в сфере информационной безопасности (ИБ) уже больше 10 лет.

В 2021 году я начал масштабное исследование трудоустройства 400 QA-студентов более десятка различных курсов. Исследование получилось настолько длинным, что превратилось в дюжину хабр-статей с 500'000 просмотрами, а некоторые из его участников успели пройти путь от "какой курс посоветуете?" до "поздравьте, мне предложили позицию сеньора".

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

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

Удивительнейшим образом эти собственные данные выглядят иначе, чем числа, которые Skillbox публикует на своих лендингах.

Развитие AI-инструментов на базе современных LLM запустило в последние годы тренд на автоматизацию всего, что прибито меньше, чем на 2 гвоздя, и первыми адоптерами здесь традиционно выступает IT сообщество. Как Луи Пастер некогда ставил себе и друзьям намешанные на голой коленке вакцины, так сейчас разработчики активно ставят Code Copilot-ы, дизайнеры экспериментируют с Midjourney, скромно к этой очереди пристраиваемся и мы, Product Manager-ы.

Меня зовут Алексей, и я более 15 лет занимаюсь управлением b2b-b2c продуктами и руководством командами в энтерпрайзе и стартапах.

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

Специалисты fullstack QA весьма востребованы работодателями. В сегодняшней статье расскажу, в чем ценность таких сотрудников, какие hard и soft skills нужны и почему будущее именно за fullstack QA.

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

Эта статья целиком посвящена сканированию сетевой инфраструктуры — второму этапу пентеста, который следует после разведки. Если при разведке мы ищем IP-адреса и различные точки входа в инфраструктуру, то при сканировании — внимательно исследуем все найденное. Под катом вас ждет база — те вещи, которые должен знать каждый начинающий пентестер, занимающийся аудитами внутренней инфраструктуры.

Около 90% наших проектов связаны с доменом, поэтому сначала поговорим про работу с Active Directory. Начнем с терминологии и затем перейдем к практике.

В небольшой комнате студенческого общежития Калифорнийского университета группа молодых людей напряженно разглядывала синюю коробочку. Это были Джон Дрейпер, Стив Джобс и Стив Возняк. Они проверяли свое изобретение и собирались совершить бесплатный звонок в Ватикан. 

После нескольких попыток на другом конце провода ответили. Взволнованный Стив Возняк, едва сдерживая смех, произнес: «Это Генри Киссинджер, я должен немедленно поговорить с Папой Римским. Я должен признаться в своих преступлениях». 

Джон Дрейпер всегда вспоминает этот случай с улыбкой. Именно он сумел взломать телефонную систему и научил этому будущих создателей Apple. Это история о программисте, который, по его собственному выражению, «прошел путь от хакера без гроша в кармане до миллионера и обратно».

Мы продолжаем рассказывать о внутренней кухне Wiren Board. В предыдущей статье мы заставили работать китайский паяльный робот, который выполняет рутинную часть работы монтажников на нашем производстве.

Все наши «железки» должны поступать клиентам в рабочем состоянии и служить максимально долго. Именно по этой причине после производства все устройства проходят тестирование.

Расскажем, как разрабатывали фирменный тестовый пакет test-suite, с какими проблемами столкнулись и как мы их решили. Также покажем наши стенды, на которых тестируем все выпускаемые продукты.

Интересно? Ныряйте под кат.

Часто автотестирование кажется новичкам чем-то невероятно сложным и недостижимым. Многие думают, что для того, чтобы начать писать автотесты, необходимо сначала получить глубокие знания в программировании, разобраться во всех технических тонкостях ручного тестирования и только лишь потом пробовать писать автоматизированные тесты.

Это, конечно, не так. Я предлагаю вам познакомиться с Robot Framework — инструментом, который позволит писать автотесты, даже если у вас не было никакого опыта программирования.

Труднее всего тестировщику приходится в ситуациях, где даже не подозреваешь, что действуешь неправильно.

Сегодня я разберу 6 кейсов, с которыми время от времени сталкивается каждый QA, которые на первый взгляд кажутся не сложными, но потом становится ясно, что они приводят к неожиданным проблемам, незнание которых может сильно осложнить тестирование, а в худшем случае привести к проблемам релиза.

В software-разработке с автоматизацией обычно все неплохо: более-менее понятно, как настроить CI и автоматизировать отдельные этапы CI-конвейера. Есть множество готовых решений и практик. Но, когда речь заходит об автоматизации тестирования на «железе», появляется множество нюансов. Например, не всегда понятно как автоматизировать процессы, которые обычно делают люди, — банальную перезагрузку устройства в другом городе. Или другая особенность — целевые аппаратные ресурсы масштабируются не так хорошо, как софт, поэтому приходится придумывать свои подходы к распределению времени доступа к стенду для СI-конвейеров и инженеров.

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

Всем привет! Я Настя — QA команды, которая занимается развитием и поддержкой публичного API hh.ru. В этой статье расскажу, как мы проверяем OpenAPI-документацию в тестах при помощи автогенерации классов и валидации.

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

Тот пост оказался довольно популярным и вызвал обсуждения, повлиявшие на то, как я делаю это сегодня. И спустя годы ведения подкаста Go Time, обсуждения Go в X/Twitter и поддержки подобного кода я решил, что настало время обновить информацию.

(Если вы педант и скажете, что Go не совсем 13 лет, то я отвечу, что начал писать HTTP-сервисы на Go версии .r59.)

В этом посте рассматривается широкий спектр тем, связанных с созданием сервисов на Go

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

Под катом мы подготовили практический шаблон, который поможет вам в этом.

Всем привет! Меня зовут Александр, я работаю в SM Lab на позиции куратора тестирования. Сегодня я хотел бы поговорить о такой интересной вещи как CJM на продукте и о том, чем она может быть полезна тестировщику.

Начнем с определения — что такое CJM.

CJM (от англ. customer journey map) воспроизводит путь, который проходит клиент от осознания потребности в продукте до его покупки, а иногда и после неё. Всё это время он взаимодействует с продуктом и компанией и принимает решение на основе полученного опыта. Другими словами, это визуализация путешествия клиента по продукту