Организация контрактного тестирования микросервисов и графического портала

Помогите разобраться и организовать качественное тестирование. Есть одна система, которая разрабатывается в двух разных компаниях. Есть так скажем ядро, которое состоит из разных функциональных модулей, которые общаются церез API. И есть графический портал, который общается с ядром через предложенные RESTAPI. Я так понимаю, что компания, где идет разработка ядра, должна сделать Юнит и интегрейшн тесты + сделать контрактное тестирование и протестить енд пойнты. А как быть с компанией, где разрабатывают графический? Как лучше синхронизировать тестирование, если это, вообще возможно? Или тестировщики в каждой компании тестируют независимо друг от друга? И как быть с тест планами? Каждый делает свои или общий? И как быть с автоматизацией? Для API используем SWAGGER.

1 лайк

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

Да так и есть. Я всегда был ответственнен за проекты внутри компании, но теперь достался такой проект с микросервисами, с которыми впервые сталкиваюсь и если учесть, что в другой компании только один тестировщик, то всё поручили мне. И чем больше я читаю про тестирование микросервисов, тем больше возникает вопросов.

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

7 лайков

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

3 лайка

На вас хотят ездить, а вы говорите что это не так критично.
Тут два варианта - просить прибавку к ЗП, либо сруливать.

А по факту - тестирование ядря должно покрываться компанией, которая ведёт разработку ядра.

Что именно вы хотите просинхронить?
Со стороны графического интерфейса это уже будет просто проверка то что кнопочки работают.

image

2 лайка

подобный вопрос уже был, где в комментариях был описан подход

1 лайк

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

a mozno vot etot moment utochnit’ ? Chochetsia bolshe konkretiki

Подробнее было так: А где описание того, как мы синхронизируем тестирование, чтобы перед сдачей клиенту быть уверенными, что всё работает, что всё покрыто тестами.

Весь покрытый тестами, абсолютно весь
Код в репозитории на Github’е есть…
:musical_score::saxophone::musical_keyboard:

2 лайка

интересные коллеги у вас

то есть сейчас они не тестируют вообще, а когда вы предлагаете хоть какую-то стратегию, начинают задавать идиотские вопросы?

В этой фразе прекрасно все :slight_smile:

4 лайка

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

1 лайк

Каждый компонент (BE, FE) тестируется по спекам. REST API должен быть заранее задокументирован и не меняться.

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

Возможно будет возможность интегрироваться поэтапно по фичам, эпикам…

Чем сложнее система, тем всё сложнее…

3 лайка

а эти 2 системы сейчас пишутся с нуля? Если нет, то стоит узнать какой процесс тестирования на данный момент, т.е. как-то это всё работало, наверное, до вас

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

  • команда разработчик API тестирует все у себя (как бы понянто и так), также если есть микросервисы и они между собой “общаються” - это тоже тестируют в основном они и автотестами;

  • команда разроботчик портала - у нее все сложнее. Можно договориться брать самые свежие версии кода API или доступ к инстансу где бекенд последней версии и против них проганять небольшой сьют, который проверяет корректность моделей, основных сущостей, обьектов и валидирует что все хорошо. Это может быть простые вызовы с Postman - не true way, или уже сьют на удобном языке с автоматическими тригеррами и репортами, плюс “светофором” чтобы все видели current state. Если что-то падает, сразу информировать команду-разработчика API и для них это должна быть задача “блокер”;

  • еще команде разработчику портала лучше иметь хороший сьют e2e тестов, так как при разработке связанных микросервисов часто бывает, что сервис сам по себе протестирован и в связке с другими вроде хорошо протестирован, но на клиенте “бока”… Сдесь тяжело разорбаться кто виноват и если уверены, что не клиентская часть (портал), то в основном надо “умело” читать логи бекенда и понимать что он делает не так, или иметь человека на другой стороне, чтобы попросить помочь разобраться в проблеме. Опять таки, можно договориться, чтобы такой челевек всегда был, или какой-то общий канал (типа как в Slack) и туда писать о найденых или потенциальных проблемах.

Если плюс-минус такая модель начинает работать, то со временем обьем тестов на обеих сторонах растет, что позволяет быстрее привентировать несовместимости.

5 лайков

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

Команда пользователь апи тестирует свою логику, и если они решают вам не доверять то сверху ещё могут замазать все е2е или тестами на контракты апи. В зависимости от тех ресурсов которыми они располагают.
Тестироваться вы вообще можете отдельно.

Синхронизировать вас будет версия апи.

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

2 лайка

Возможно вам будет проще если задачу рассматривать не как единое целое. А как две задачи: организовать тестирование в одной команде и организовать тестирование в другой команде.

Для организации независимого контрактного тестирования между сервисами существует специальная библиртека PACT. Реализованна на различных языках програмирования

2 лайка