Привет, Хабр! Ухудшение работы YouTube стало поистине трагическим событием, которое прибило почти все загрузчики видео, но я нашел легальный способ улучшить ситуацию! Как починить оборудование Google, не привлекая внимание санитаров.

Привет, Хабр! Меня зовут Кирилл Веркин, я Senior QA в СберМаркете. Эта статья о том, как за 1,5 года моя команда прокачала уровень инженерной культуры с нуля до самого высокого среднего балла в компании среди 105 команд. 

(Да, у нас есть уровни инженерной культуры!) Хочу рассказать, как мы их оцениваем и повышаем, почему это круто бустит развитие и как соревновательный аспект делает жизнь инженера гораздо интереснее. А ещё это история о том, как у меня получилось повлиять на командный результат будучи тестировщиком — на заметку тем, кто хочет не только расти сам, но и «менять мир».

Здравствуйте, коллеги.

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

Само собой, если вы проходите собеседование на позицию junior, от вас не будут требовать опыта и знаний по всем вопросам. Будет круто, если вы разбираетесь хотя бы в ~30% всего этого. От позиции middle я бы ожидал примерно ~50%-60% знаний перечисленных мною тем. Ну и далее по восходящей.

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

Привет, друзья! В этой статье предлагаем вам решить десяток задач по автоматизации на Python + pytest. К каждой задаче приложили наш вариант решения.

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

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

Предыдущие части

• Часть первая — habrahabr.ru/post/255361
• Часть вторая — habrahabr.ru/post/255523

О чем будет рассказано в этой части

1. с выражением CASE, которое позволяет включить условные выражения в запрос;
2. с агрегатными функциями, которые позволяют получить разного рода итоги (агрегированные значения) рассчитанные на основании детальных данных, полученных оператором «SELECT … WHERE …»;
3. с предложением GROUP BY, которое в скупе с агрегатными функциями позволяет получить итоги по детальным данным в разрезе групп;
4. с предложением HAVING, которое позволяет произвести фильтрацию по сгруппированным данным.

Привет, меня зовут Коля, занимаюсь тестированием 7 лет, автоматизацией — 6 лет. Так уж сложилось, что не особо люблю WebUI-тесты, но почему-то именно они у меня получаются лучше всего.

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

Отправив Роме ссылку на свой гитхаб и устроив пару созвонов с объяснениями, что и как работает, я добился от него заветного «Я понял». 

Спустя два дня Рома позвонил снова: «Коля, я всё понял, а вот ребята в моей команде — нет. Помоги мне объяснить им».

Внутри я расскажу от том, как:

• ускорить написание тестов;

• снизить затраты на их поддержку;

• прокачаться в написании фреймворков;

• сэкономить деньги компании;

• сохранить нервы сотрудников.

Привет! Я Линар Юнусов, тестировщик из мобильной команды СберМаркета. Если вы не первый день в тестировании, то знаете про существование нефункциональных проверок и как они могут поломать жизнь (зачеркнуто) приложение. В этой статье расскажу про то, к каким проверкам мы пришли в СберМаркете. Сначала поговорим о довольно популярных кейсах, потом о более специфических: попадём на экраны настройки в режиме разработчика, попробуем поработать с клавиатурой и вводом эмодзи ?, а ещё узнаем скорость загрузки нашего приложения на разных платформах. Поехали!

Привет! Меня зовут Глеб Гончаров, я руководитель группы разработки клиентского продукта в СберМаркете. Это вторая часть в серии статей об истории развития самого популярного протокола Всемирной паутины — протокола HTTP.

В первой части я рассказал про старую группу протокола HTTP  (HTTP/0.9, HTTP/1.0, HTTP-NG, HTTP/1.1): причины их появления, видах запросов и недостатках. Сегодня же поговорим о новой группе, которая включает в себя протоколы SPDY, HTTP/2, gQUIC и HTTP/3.

Привет! Меня зовут Артём Комаренко, я работаю на позиции QA Lead в команде PaaS в СберМаркете. Хочу поделиться историей, как мы придумывали способ быстро убедиться, что очередные изменения в скриптах деплоя не разломают процесс выкатки во всей компании. Статья будет полезна QA-специалистам и DevOps-инженерам, которые хотят автоматизировать тесты инфраструктуры.

Привет! Меня зовут Евгения Воропаева. Я занимаюсь тестированием в PIMS-команде СберМаркета, мы разрабатываем внутреннюю систему для отдела контента и производства. Проект существует уже 2,5 года и за это время PIMS рос и развивался, приходили и уходили люди, менялись подходы к работе, внедрялись новые практики. Методом проб и ошибок мы выстроили процессы в команде тестирования, которые считаем оптимальными. Хочу поделиться результатом, к которому мы пришли и надеюсь, наш опыт будет вам полезен.

Привет! Меня зовут Глеб Гончаров, и я руковожу подгруппой ИТ-инфраструктуры в СберМаркете. В работе мы широко используем Kafka как шину данных для микросервисов и не раз убедились на практике, что к инструменту важно подобрать правильный подход. Об этом сегодня и поговорим в двух частях — сначала обсудим основы, а в конце статьи будет ссылка на практические задания.

Привет, Хабр! Меня зовут Александр Меркулов, я занимаюсь разработкой более 20 лет, с 2011 года пишу на Ruby. Сейчас я — backend-техлид в Учи.ру. Наша команда использует большой монолит, который написан на Rails. Также мы создаем и поддерживаем микросервисы, у нас есть нативная мобилка: целых четыре приложения под веб-платформу.

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

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

Как правильно писать UI авто тесты на python используя Page Object + Page Factory.

Привет, Хабр! Меня зовут Александр Бехтерев, я работаю QA-инженером в Учи.ру. Не так давно перед нами встала задача перехода с библиотеки Selenium на новую и мощную библиотеку Playwright. Этот переход был вызван желанием улучшить процессы тестирования и попробовать что-то новое. 

В этой статье я постараюсь подробно рассмотреть процесс создания проекта на Python, Pytest и Playwright с применением паттерна Page Object, а также оставлю шаблон yml, который позволит запускать автотесты в CI. 

Как правильно писать API авто тесты на Python используя Pytest, Pydantic, Httpx, Allure.

Эта статья как продолжение статьи Как правильно писать UI авто тесты на Python. Если мы говорим про UI автотесты, то тут хотя бы есть паттерны Page Object, Pagefactory; для API автотестов таких паттернов нет. Да, существуют общие паттерны, по типу Decorator, SIngletone, Facade, Abstract Factory, но это не то, что поможет протестировать бизнес логику на уровне API тестируемой системы

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

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

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