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

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

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

Хорошая практика, когда сначала по нему проходишь сам, а потом уже отдаёшь коллеге в более чистом виде. С ним, кстати, удалось и подтянуть менее опытных коллег — например, они использовали его как шпаргалку, где ожидаемый результат должен быть 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, который часто упоминается в контексте микросервисной архитектуры. Этот шаблон основывается на использовании шлюза, находящегося между клиентскими приложениями и микросервисами, предоставляя единую точку входа для всех клиентских запросов.

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

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

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

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

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

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

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

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

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

Привет, Хабровчане!

Меня зовут Андрей Беляев, и я занимаюсь расширением возможностей организаций, внедряя ИИ-помощников.

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

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

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

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

Меня зовут Сергей Громов, я работаю в IT уже 30 лет. Прошел путь от программиста на Assembler и преподавателя до ведущего системного аналитика.

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

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

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

Сегодня я расскажу о нашем внутреннем пространстве для экспериментов под названием «Гараж». Его главная идея – предоставить сотрудникам комфортную и понятную площадку для проверки гипотез и реализации новых инициатив. Это своеобразный инкубатор, построенный по принципу трайба и полностью интегрированный в структуру компании.