Всем привет! Меня зовут Сергей Герасимов, я – Senior QA Manual Engineer (да, хвастаюсь) в компании “Петрович-Тех”.

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

Звучит просто, но что кроется за ней?

В своей прошлой статье я рассказывал о тестировании оплат, техниках тест-дизайна, которые использовал, и всячески открещивался от попарного тестирования. Но вот злой рок дошел до меня, и сегодня я расскажу о недавнем опыте использования “попарки” на практике. 

Привет, Хабр! Меня зовут Марина, и я бизнес-аналитик в Петрович-Техе. 

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

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

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

Привет, Хабр! Меня зовут Дима, я руковожу отделом информационных технологий бэк-офиса в “Петрович-Тех”.

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

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

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

Привет, Хабр! Меня зовут Сергей, я тестировщик в “Петрович-Тех”. В этой статье хочу поговорить о комбинировании различных техник тестирования и поделиться опытом тест-дизайна для проверки системы оплаты.

На всем своем профессиональном пути тестировщика я так или иначе всегда работал с оплатами (люблю деньги, что поделать). Вместе с командой Петрович-Тех успел поучаствовать во внедрении оплаты частями, добавлении СБП, полном редизайне корзины в интернет-магазине, сейчас тестирую оформление заказа.

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

В известном смысле это основы тестирования, но по моему опыту как раз из-за этого (“это база, ну что там может быть такого”) о подобных вещах на практике забываешь чаще, чем хотелось бы. К тому же в любом домене есть свои тонкости, в случае проверки систем оплат – налоги, чеки, возвратные чеки, регионы, экономические зоны. Кажется, для насмотренности может быть полезно разобраться, как тест-дизайн адаптируется под эти нюансы. 

Приступим!

Привет, Хабр! Меня зовут Дима, я руковожу отделом информационных технологий бэк-офиса в “Петрович-Тех”. Мы разрабатываем ИТ-решения для Петровича, крупного федерального ретейлера в сегменте DIY и строительных товаров.

За последние несколько лет компания существенно выросла (в продажах – в 10 раз за 10 лет, до 119 миллиардов рублей без НДС в 2022). Требования к надежности и стабильности ИТ — росли соответственно. 

Наверное, каждый из вас сталкивался с ситуацией, когда ИТ-сервис был недоступен в самый неподходящий момент. Чтобы не ходить далеко за примерами: такое случается даже с распространенными коробочными решениями уровня “практически индустриальный стандарт”, вроде JIRA или Confluence. 

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

Мы понимаем, что могут быть сотни факторов, из-за которых все идет не по плану — и в разработке, и в сопровождении ИТ-сервисов. Чтобы бизнес тоже это понимал и строил планы с учетом этого знания — нужен некоторый общий контекст, договоренности об уровне услуг. Если согласовать подобные вещи, выиграть могут все: коллегам из бизнеса будет понятнее, что происходит; людям из ИТ – спокойнее за принятые на себя обязательства.

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

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

Привет, Хабр! Меня зовут Данил, я директор по развитию стратегических проектов в СТД “Петрович”. Давайте поговорим о проектном управлении на длинной дистанции – как теоретическая целевая модель процессов реализуется на практике. 

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

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

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

Когда-то подобное могло случаться и у нас. Сейчас – за последние полгода только 1 проект из 15 был отправлен на доработку и благополучно прошел защиту со второго раза. Такое изменение стало возможно благодаря новой модели проектного управления.

Давайте расскажу, как устроена эта концепция.

Привет, меня зовут Дима, я ведущий ИТ бизнес-партнёр в Петрович-Тех. Сегодня расскажу вам историю о том, как мы запускали продуктовый подход в инхаус-разработке.

В 2020 году задачи бизнеса сыпались в «общий котел», коллеги из бизнеса буквально бились за ИТ-ресурсы по принципу «чьё важнее». Команды разработки формировались по принципу «кто делал что-то похожее», оценки делались примерные, с умножением на «пи» или на «е».

Эта статья о том, как мы разбирали 1С УТ на продукты и сервисы, запускали “почти что Scrum-подход с элементами Kanban”, учились отвечать на вопросы “сколько ждать хотя бы примерно?” и “когда уже будет готово?” через метрики и перцентили – и как в конечном итоге благодаря продуктовому подходу нам удалось удвоить пропускную способность команд.

Привет, меня зовут Андрей, я тимлид в Петрович-Тех. Хочу сегодня поговорить с вами об 1С-разработке в общем и OneScript в частности. 

На сегодняшний день скриптовый язык OneScript – уже практически стандарт для 1С-разработчиков. При этом несмотря на распространённость и широту применения, я не могу сказать, что там всё очевидно. Я сам с опытом 1С-разработки в 10 лет всё ещё продолжаю узнавать нетривиальные нюансы работы с OneScript на уровне базовых сущностей; например, из недавнего – как в OneScript делается autocomplete. 

Входной порог в OneScript – есть.

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

Надеюсь, статья будет полезна для разработчиков и тимлидов в 1С-командах, а также специалистам из поддержки, кому по работе случается сталкиваться со скриптами на 1С.

Привет, Хабр! Меня зовут Дима, я руковожу отделом в Петрович-Тех. Мы делаем ИТ для строительного ритейла, моя команда занимается поддержкой. В статье хочу рассказать о том, как мы наводили порядок в работе с бэклогом для внутреннего продукта – что делать, когда постоянно много задач, приоритеты меняются, стейкхолдеры недовольны. 

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

По сравнению с внешними, внутренние продукты зачастую “догоняют”. Для внешних – 2-недельные спринты и разные там CI/CD; для внутренних – непрерывный поток задач, задачи берутся в работу по мере поступления. Работа делается, но сложно давать прогнозы, когда что будет готово — в любой момент времени может прилететь непредсказуемое количество задач, которые поменяют все планы. Не хватает людей на развитие внутренних продуктов – “вот сначала разберёмся со срочными задачами бизнеса, тогда займёмся этим”.

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

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

Давайте расскажу, как мы к этому пришли.

Привет, я Алексей, QA Automation Engineer в команде «Интеграции» в Петрович-ТЕХ. Занимаюсь разработкой фреймворка автоматизированного тестирования сервисов интеграции, для REST и SOAP. 

Наблюдение: когда приходишь на собеседование на должность Junior QA Automation, то обязательно просят разработать автотесты для API. Звучит логично, но не так уж и просто: когда только начинаешь свой путь в автотестировании, тебе не всегда очевидно, как должен выглядеть рабочий тестовый фреймворк, из чего он должен состоять, как правильно написать тесты, а к ним тестовые данные. «Сырые» тесты, которые описывают в книгах и разных источниках – не всегда выручают.

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

Надеюсь, статья будет интересна начинающим авто-тестировщикам и тем, кто уже разрабатывает автотесты для API.

Организация Петрович-Тех как отдельная ИТ-компания была создана весной 2022. В тот период многие организации выделяли свои ИТ-подразделения в отдельные компании с расчётом на льготы от государства (кредиты с пониженной ставкой, налоговые послабления и другое). 

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

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

Привет, меня зовут Павел Купцов, я —  QA в Петровиче. До QA я добирался несколько лет окольными путями: через техникум, работу грузчиком и «эникейщиком», упорное обучение, когда курсы нужно было искать, а не они находили тебя, через отчаяние и уныние. Но в итоге я добился чего хотел и достиг личного успеха, как бы пафосно это не звучало. 

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

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