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

Предыстория

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

За несколько итераций проведённых 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. Пропали топики (раньше топики отображались, а теперь нет, хотя параметры подключения не менялись)

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

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

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

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

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

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

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

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

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

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