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

Всем привет! Недавно в блоге выходила статья, в которой мой коллега Александр Волков рассказал про применение практик хаос-инжиниринга, продемонстрировал поведение системы при сбоях на примере демосервиса, оценил его отказоустойчивость и предложил стратегии для улучшения архитектуры. А в этой части я, Екатерина Ильина — QA-инженер Cloud.ru, расскажу, как мы решили собственноручно сломать наши сервисы, чтобы сделать их отказоустойчивее.

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

С увеличением масштабов и сложности программного обеспечения требования к его качеству становятся всё выше. Ранее использовавшиеся подходы к обеспечению качества (QA) уже не всегда справляются с текущими вызовами, особенно когда речь идет об интеграции тестирования в рамках непрерывной разработки и доставки (DevOps). Появление подхода QAOps знаменует собой новый этап в эволюции тестирования: это попытка обеспечить максимально тесную интеграцию QA и DevOps, где тестирование становится неотъемлемой частью каждого шага разработки.

Привет, Хабр! Меня зовут Алексей, я QA-специалист в компании SimbirSoft. Моя статья будет полезна:

- QA-инженерам, которые хотят улучшить свои навыки и узнать о новых подходах в тестировании, 

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

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

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

Привет, меня зовут Георгий Ломакин, и я инженер по нагрузочному тестированию в компании Picodata — разработчике одноимённой NewSQL СУБД. В этой статье я поделюсь своим опытом нагрузочного тестирования и расскажу, как мы строили эту практику с нуля.

Мы выбираем распределённые системы за производительность и надёжность. Однако без постоянного нагрузочного тестирования и анализа отчётов после него, и то и другое лишь обещания. Конечно же, нагрузочное тестирование обязательно и в нашей команде, разрабатывающей распределённую NewSQL — базу данных Picodata.

Поскольку в последнее время часто вижу рекламу “войти в IT”, решил посмотреть и дать картину того, кто выступает в качестве менторов и стоит ли им доверять на примере наставников в тестирование.

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

Цель этой статьи - дать несколько советов и рекомендаций по управлению важнейшим компонентом тестирования сервисов, упомянутым в этой статье, а именно, барабанная дробь, ... тестированием производительности! 

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

Я в тестировании уже полтора года и в последнее время активно использую ChatGPT в своей работе. К сожалению, мое с ним взаимодействие не сразу принесло плоды. Поэтому я решил переложить свой опыт проб и ошибок в написание гайда, который подскажет читателям блога ЛАНИТ на Хабре, как и зачем применять ChatGPT в задачах инженера функционального тестирования.

Привет, Хабр! Я – Мария Скрипачева, тестировщик в АйТи-Балансе. Сегодня почти все компании применяют тестирование, и мы не исключение: наши проекты проходят несколько стадий проверок до развёртывания. На нынешнем месте работы я иногда встречаю вопрос, с которым не раз сталкивалась на предыдущих: «а нужен ли GitHub тестировщику?». Эта дискуссия не нова. Я решила внести свою лепту в обсуждение, опираясь на мой опыт и опыт моих коллег, и заодно рассказать о фундаментальных вещах. Поехали🚀

Статья будет полезна разработчикам встраиваемых систем, которые хотят автоматизировать процесс тестирования своих проектов. Отдельный блок посвещен отладке gdb в эмуляторе QEMU. В качестве примера используется библиотека логирования (GitHub, Habr)

Привет, Хабр! Меня зовут Илья, и я работаю инженером в компании STEP LOGIC. За последнее время я и мои коллеги накопили определённый опыт развёртывания отечественных почтовых систем, в кластерных конфигурациях, в т.ч. в промышленной эксплуатации. В этой статье я расскажу о нем и особенностях наиболее крупных и известных российских почтовых систем.

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

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

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

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

Привет, коллеги и любопытствующие читатели! Меня зовут Андрей Ахметов, я главный инженер ЦК-тестирования в РСХБ-Интех.

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

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

В статье расскажу о том, как строится весь процесс, о технических сложностях и закулисье...

Добрый день! Меня зовут Анастасия, я QA-инженер команды бэкофиса в «Финаме». С 2022 года занимаюсь тестированием бэкофисных и торговых систем финансовых компаний. До перехода в QA работала в эксплуатации и поддержке торгово-клиринговой системы СПБ Биржи.  Моя сильная сторона — глубокое понимание бизнесовой части тестируемого продукта.

За 5 лет работы в компаниях-участниках финансового рынка РФ я осознала: тестирование продуктов в финансовой компании не равно классическому тестированию. QA-инженер в сфере финансов отличается пониманием предметной области для обеспечения качества, особой усидчивостью, а также навыком работы с большим количеством данных.  

В среде людей, так или иначе связанных с компами, циркулирует огромное количество мифов, связанных с термопастой и ее использованием. В интернетах разгораются жаркие споры о том, надо ли ее менять или не надо, если надо, то на какую — КПТ-8 или подороже и как часто ее нужно менять. Огромное количество сервисменов вовсю эксплуатирует миф о том, что термопасту надо менять как зубную щетку — чуть ли не каждые полгода и делают на этом неплохие деньги. Ведь замена термопасты предполагает необходимым только один навык в обслуживании техники — разобрать ее, а потом собрать в обратном порядке, не забыв при этом вкрутить все необходимые винты (хотя даже это некоторым дается с трудом, во многих попадавших ко мне ноутбуках после такого «обслуживания» отсутствовали 1–2 винта).

Привет, Хабр! Меня зовут Вика. В СберТехе я занимаюсь разработкой продукта Platform V Works:Test Data Management (TDM). Инструмент помогает QA генерировать необходимые синтетические тестовые данные по клику, а не обращаться к смежным командам и тратить на это время. Менеджерам TDM помогает сокращать time‑to‑market продуктов, поэтому лететь на другую планету ради тестов больше не придётся. В этом материале я расскажу, как мы поняли, что нам нужен отдельный инструмент для генерации, какие показатели у нас были в начале пути и к чему пришли сейчас. Поехали!

Если бы мы организовывали предновогодний корпоратив «здорового» гофера, он выглядел бы так. 12 декабря, в четверг, собираем Go-разработчиков в Нижнем Новгороде и онлайн, чтобы обсудить практики тестирования микросервисов на Go, историю распила монолита, которая привела к… монолиту, и работу с монструозным Makefile (ждем откровений Даниила Подольского). В качестве нетайных Сант выступят эксперты из Wildberries, YADRO, Ви.Tech и Weborama — спикеры и участники GolangConf. 

Чтобы почувствовать приближение Нового Goда, регистрируйтесь на офлайн-участие — сможете поучаствовать в технических интерактивах и получить подарки. А если вы не в Нижнем, присоединяйтесь к последнему Go-митапу в 2024 году онлайн.

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

Я Александр Волков — QA Lead в Сloud.ru. В статье на примере демосервиса онлайн-магазина покажу, как мы применили практики хаос-инжиниринга, проверили поведение нашей системы при сбоях, оценили ее отказоустойчивость и в итоге выработали стратегии для улучшения архитектуры.