Привет, Хабр! 

Пишет вам Зураб Белый, айтишник, а по совместительству — один из ведущих подкаста «Скрамное ИТ». Вот о нем, родимом, сегодня и пойдет речь. 

Собственно, спешу сообщить: у нашего подкаста новый сезон, новый формат, новое качество. В общем, все новое, только лицо старое (ну, три лица, точнее). Да, мы не сменили состав — Леонид, Савелий и я, ваш покорный слуга — Зураб, все так же в строю. Но все остальное вокруг нас сильно поменялось. Те, кто с нами уже давно, конечно, помнят наши прошлые сезоны: сначала был только звук, потом добавили картинку, и теперь мы перезагрузились полностью. Студия, оборудование, оформление, качество съемки и подхода к подготовке материалов. А главное — контент. 

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

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

И вот, наш первый выпуск в этом новом формате... Ну, на мой (разумеется, предвзятый) взгляд, он получился отличным, как по форме, так и по содержанию. Наша первая тема — «Гуманизм vs Искусственный Интеллект. Как развивать технологии, чтобы не потерять смысл жизни?». Сильно спойлерить не буду, но вот несколько тезисов, вокруг которых разворачивалось обсуждение. 

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

Предыстория

У нас двухнедельные спринты, в рамках которых с определённой периодичностью проходят груминги, на которых мы не только приоритизируем задачи, но и разбираем аналитику. Происходит это так: на регулярных встречах собирается вся команда, аналитики презентуют нам новую фичу/задачу, а мы задаём вопросы. Если все вопросы решены, либо что‑то можно быстро уточнить/устранить, то команда двигает эту задачу в статус «Готово к разработке». И мы командой тестировщиков определили, что во время грумингов презентация аналитики происходит быстро, мы не успеваем параллельно читать и слушать пояснения, а также придумывать на ходу вопросы. Нужен был процесс по тестированию требований.

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

Привет, Хабр!

Ранее мы разбирались с основами Kafka (часть1), рассматривали, как тестировать микросервисы (часть2) и предугадывали ошибки offset explorer и kafka ui (часть 3). В этой части – так сказать, невошедшее, но полезное, что ещё можно предусмотреть при работе с брокером. 

Преимущества брокеров

Когда я готовила материал из первой части, у меня возникло несколько предположений. Мне казалось, что некоторые преимущества относятся именно к брокерам сообщений и не имеют прямого отношения к API (временное хранение данных, обмен в реальном времени, вычитка раз в сутки, отслеживание Kafka-лага). Особенно я задумалась об этом, когда разбирала пример с мобильным веб-приложением и форматами данных для Kafka (см. раздел из статьи часть1). Казалось бы — зачем Kafka, если можно просто забирать данные из БД через API?

Я решила проверить свои догадки у знакомого бэкенд-разработчика. Его первый вопрос был: «Зачем тебе как тестировщику это знать?», а потом добавил, что API можно настроить похожим образом. Но всё же я выделила два ключевых отличия брокеров: 

1. Асинхронное взаимодействие

API — это всегда запрос-ответ. Если сервис упал, мы получим 503, и данные могут потеряться. В Kafka продюсер просто оставляет сообщение в топике, и ему всё равно, читает ли его кто-то. Даже если консьюмер упал — поднимется и дочитает. 

2. Масштабируемость

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

Привет, Хабр!

Во второй части мы разобрали, как тестировать микросервисы с кафкой. В этой части – лайфхаки при работе с offset explorer и kafka ui в формате чек-листа для удобства периодического возвращения к статье при необходимости. 

Когда вы впервые подключаетесь к кластеру Kafka или продолжаете работу с ним, могут возникать различные трудности. Перед тем, как обращаться к разработчику, DevOps-у или коллеге-тестировщику, проверьте эти пункты, возможно, проблема на вашей стороне. А даже если не на вашей, вы точнее определите проблему 😊

1. Пропали топики (раньше топики отображались, а теперь нет, хотя параметры подключения не менялись)

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

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

Начнем с главного — непрерывное обучение. Сейчас это, на мой взгляд, необходимость, а не выбор.

Современный ИТ-специалист уже не может ограничиться знаниями, полученными в университете или на первых этапах карьеры. Технологии устаревают быстрее, чем когда-либо, а требования рынка постоянно растут. Lifelong learning (непрерывное обучение) — это не просто модный тренд, а обязательное условие для поддержания профессиональной релевантности.

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

И снова привет, Хабр! Любите ли вы чек‑листы так, как люблю их я?

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

В этом процессе осознали, что каждый обращает внимание на что‑то своё, и пора бы это стандартизировать и расшарить на команду (обмен опытом, наш любимый). Так был создан чек‑лист проверок для ревьюера тест‑кейсов.

Хорошая практика, когда сначала по нему проходишь сам, а потом уже отдаёшь коллеге в более чистом виде. С ним, кстати, удалось и подтянуть менее опытных коллег — например, они использовали его как шпаргалку, где ожидаемый результат должен быть 400, а где — 404, какие проверки валидны, какие — уже и нет, а какие — следует добавить. Поехали!

Чек-лист для ревьюера тест-кейсов

Качество требований в IT-проектах — тема, которая редко обходится без болезненных вопросов и неочевидных ответов. Эта статья — не о критериях идеальных требований (их мы касаться не будем), а о том, как можно выстроить работу команды, чтобы этих критериев достигнуть. В основе статьи реальный кейс: я расскажу о конкретных сложностях, с которыми мы столкнулись на одном из проектов, о причинах этих проблем и методах, которые помогли не только исправить положение, но и применить данный подход на других командах.  

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

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

Мы начали анализировать ситуацию и осознали, что команда теряет очень много времени. Например, на груминг собирались все 9 участников, обсуждали User Story, но в итоге понимали, что она не готова — её нельзя отдать в разработку, а значит, нужно вернуть аналитикам на переработку. Нас это категорически не устраивало: такие циклы требовали огромных затрат времени. 

Привет, Хабр!

Это вторая часть статьи о Kafka (первая тут). Давайте продолжим разбираться.

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

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

Если автоматическая загрузка актуальной версии chromedriver (или драйвера для другого браузера) не предусмотрена. Или не работает, и мы при запуске UI-тестов получаем ошибку о том:

1. Что у нас отсутствует chromedriver

2. Не совпадает версия chromedriver и chrome (также может относиться к любому другому браузеру и его драйверу).

Всем привет!
В этой серии из нескольких статей мы разберемся, что делать тестировщику на проекте с кафкой (как впервые, так и имея какой-то опыт). Здесь я не буду говорить о брокерах и zookeeper-ах, о том, как развернуть кафку. Но мы разберемся, как её настроить и как с её помощью тестировать ваши микросервисы.

Начнём с «базы» (точнее, теории).
Apache Kafka — распределённый программный брокер сообщений с открытым исходным кодом, разрабатываемый в рамках фонда Apache на языках Java и Scala.

Привет, Хабр!

В этой статье я опишу функциональное программирование и расскажу, как оно реализовано в Java. Помимо вопроса «что это?», я постараюсь ответить на вопросы «зачем?», «когда?» и «как?» это используется.

Привет, Хабр! 

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

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

Сначала немного о теории

Давайте вспомним различные методы выявления требований и определим место опроса среди них. 

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

Привет, Хабр! 

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

Привет, Хабр!

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

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

В нашем случае требования к кандидатам на стажировки или дообучение выставляет нанимающий менеджер – руководитель той практики, в которую потом пойдет стажер, например, для джунов-джавистов – руководитель практики Java, а для джунов-тестировщиков – руководитель практики тестирования и т.д.

Тем не менее, не секрет, что для большинства обязательным требованием стоит наличие высшего образования, и я попробую объяснить почему.

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

Зачем идти в вуз, в целом понятно, а вот зачем, как мне кажется, можно пойти в колледж?

Привет, Хабр! 

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

Привет, Хабр!  

В прошлой статье мы начали разговор о паттернах микросервисов (Часть 1). Ну что ж, давайте продолжим!

Паттерн «API-шлюз» (API Gateway)

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

Привет, Хабр! 

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

Еще раз (более явно) предупреждаю, что эта статья — размышление. Практической пользы от ее прочтения вы не получите, зато можно обсудить, кто прав, а кто ошибается, в комментариях. =) 

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

Давайте сначала рассмотрим позитивную сторону. (Все написанное — мое личное мнение, местами даже чем-то подкрепленное).

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

Я расскажу о тактике, которая фокусируется на индивидуальном подходе и заботе, в том числе — об анти-тайм-менеджменте.

Привет, Хабр!

Вероятно, некоторые из вас помнят, что мы уже рассказывали про наш внутренний портал «Интра», который нацелен на развитие сотрудников. Сегодня речь пойдет о другом портале, созданном для укрепления внутренней коммуникации в компании. Он называется «ПРО» и представляет собой платформу, объединяющую различные аспекты жизни наших коллег вне проектов.