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

В этой статье я покажу, как сделать Telegram-бота для онлайн-магазина на Python, который позволяет пользователям просматривать каталог товаров, добавлять их в корзину и оформлять заказы. Мы также рассмотрим, как интегрировать платежи и работать с базой данных для хранения информации о товарах и корзинах пользователей.

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

Тестирование — необязательный этап разработки? Зачем подключать QA к планированию? И неужели люди правда выпускают продукты с дефектами?

Меня зовут Наталья Мурашова, я Senior QA Engineer, тренер по теории, процессам и автоматизации тестирования. Сегодня разберём, что такое тестирование, зачем оно нужно, и как работают тестировщики у нас в СИБУР Диджитал.

Docker и Kubernetes — два инструмента, которые прочно вошли в арсенал современных разработчиков. Хотите разобраться в основах контейнеризации и оркестрации? Наша статья поможет вам в этом, раскрывая ключевые концепции и принципы работы этих технологий.

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

Меня зовут Ксения Бирюкова, я владелец продукта Платформы Сфера, разработанной холдингом Т1. В одном из моих проектов мы с командой пытались проводить нагрузочное тестирование. Тогда это казалось очень сложным: пробовали тестировать каждый модуль отдельно, связь с legacy-монолитом не помогала, возникали проблемы с написанием генератора псевдо-уникальных персональных данных и многое другое. И хотя результат был достигнут, ресурсов мы потратили гораздо больше, чем планировали. В итоге собрали список ошибок и задумались, как сделать нагрузочное тестирование менее болезненным. Разберём на своих и чужих примерах.

Писать о регрессе в 2024 году — казалось бы, странная идея: каждый, кто хоть как-то связан с IT-миром, знает, что такое регрессионное тестирование и зачем оно нужно. В каждом курсе, в каждой статье для новичка о нем рассказывается. Вроде бы можно закрыть тему… Но почти каждый раз, когда на собеседовании я задаю вопрос: «Как мне выбрать тесты для регресса?», четкого ответа я не получаю. Это не зависит от уровня тестировщика, его опыта и направления. 

Из интереса я пристала к разработчикам, аналитикам, менеджерам и архитекторам с этим же вопросом, но получила лишь размытые формулировки и жалобы на то, что мы слишком долго проводим регресс и давно пора все автоматизировать. Такое происходит, потому что с виду простой вопрос содержит множество уровней, о которых обычно нет времени задуматься. Меня зовут Алена Вахтина и я ведущий специалист по тестированию в Лиге Цифровой Экономики. В этой статье постараюсь хотя бы частично рассмотреть такие подводные камни регрессионного тестирования.

Жизнь — это бесконечное совершенствование. Считать себя совершенным — значит убить себя. (Георг Гегель)

Для кого статья:

• для начинающих специалистов - подглядеть пару конструкций

• для среднеопытных - порадовать свою самооценку

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

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

AI-сервис Phind - ассистент по программированию для не программистов. Или как я автоматизировал свою рабочую задачу, не написав самостоятельно ни строчки кода.

Привет, меня зовут Виктория. Я много лет работаю ведущим инженером по автоматизации тестирования качества (QA Automation Engineer). Начинала свой путь, как инженер по качеству, занималась ручным тестированием, а затем стала инженером по автоматизации. Недавно, я проводила презентацию, как перейти из QA в QAA. И хотя есть немало статей, описывающих этот путь, я хочу поделиться с вами пятью шагами от ручного тестирования к автоматизации, которые, по моему скромному мнению, могут быть полезны другим QA.

Привет, Хабр! Меня зовут Павлова Наталия, я выпускница курса «Мидл Python-разработчик» и свежеиспеченный Python Team Lead в финтех-компании: руковожу небольшой бэкенд-командой.

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

Мне хочется поделиться своим опытом — возможно, эта статья поможет кому-то более трезво оценивать свои цели и возможности.

У нас в индустрии есть распространённый мем: мол, есть стандартный офисный IT, а есть тяжёлый диджитал. И «тяжёлый» —  это не про нагрузку, а про общий сеттинг.

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

Меня зовут Юрий, я тот самый IT-специалист или, как говорят заводчане, «цифровик». За время работы у меня накопилось столько красочных историй про IT на заводе, что хватит на пару альманахов. Но начну с поста на Хабре. Все истории реальны и без купюр (поэтому я не назвал свою фамилию, хехе).

Приятного чтения!

Привет, Хабр! Меня зовут Данил Старосек, я работаю аналитиком в проекте ЕФР в Россельхозбанке. Сегодня расскажу вам о работе в условиях the roof is on fire. Поскольку мне не совсем комфортно говорить о себе в первом лице, будем использовать условное растение, которое зовут Митроша. Митроша попытается показать вам, что испытательный срок — на самом деле это круто, и происходящий вокруг хаос ни что иное, как время возможностей. Каждый сам для себя решает — быть собачкой из мемов, сидящей в окне и пытающейся делать вид, что все нормально, работать по инструкции и ждать, что все наладится (а что будет потом — не важно), или же быть укротителем хаоса!

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

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

В этом материале поговорим о звёздах и картах, а также о некоторых инструментах, которые помогали ориентироваться по небу.

Это первая часть из серии статей. Чтобы не пропустить новые выпуски, подписывайтесь на канал!

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

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

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