testomat.io управление авто тестамиПомогите разобраться и организовать качественное тестирование. Есть одна система, которая разрабатывается в двух разных компаниях. Есть так скажем ядро, которое состоит из разных функциональных модулей, которые общаются церез API. И есть графический портал, который общается с ядром через предложенные RESTAPI. Я так понимаю, что компания, где идет разработка ядра, должна сделать Юнит и интегрейшн тесты + сделать контрактное тестирование и протестить енд пойнты. А как быть с компанией, где разрабатывают графический? Как лучше синхронизировать тестирование, если это, вообще возможно? Или тестировщики в каждой компании тестируют независимо друг от друга? И как быть с тест планами? Каждый делает свои или общий? И как быть с автоматизацией? Для API используем SWAGGER.
Вопрос наверное не по теме, но. Вас назначили ответственным за организацию тестирования и обеспечения качества в весьма сложном проекте и при этом вы никогда ни с чем подобным не сталкивались?
Да так и есть. Я всегда был ответственнен за проекты внутри компании, но теперь достался такой проект с микросервисами, с которыми впервые сталкиваюсь и если учесть, что в другой компании только один тестировщик, то всё поручили мне. И чем больше я читаю про тестирование микросервисов, тем больше возникает вопросов.
хех, м-да, ну и ушлый же у вас работодатель. Не представляю, как один человек может организовать тестирование на всех уровнях, не будучи десижн-мейкером и не имея опыта. На вашем месте плюнул бы на это слюной и отправился бы в компанию, где можно поучиться и увидеть как это делается. Не думаю, что здесь кто-то сможет дать исчерпывающий ответ на вопрос, который требует от исполнителя несколько лет опыта и высокой квалификации.
Не думаю, что прям так всё критично, чтобы увольняться. + Я не прошу сделать всё за меня, а лишь дать наводки. Может кто-то из пользователей был в таком проекте и сможет посоветовать. Может есть какой другой форум, где можно спросить у тех, кто в этой теме
На вас хотят ездить, а вы говорите что это не так критично.
Тут два варианта - просить прибавку к ЗП, либо сруливать.
А по факту - тестирование ядря должно покрываться компанией, которая ведёт разработку ядра.
Что именно вы хотите просинхронить?
Со стороны графического интерфейса это уже будет просто проверка то что кнопочки работают.
подобный вопрос уже был, где в комментариях был описан подход
Ядро разрабатывает моя компания. План я сделал: юнит, интегрейшн тесты, документация API в swagger и там же тестирования енд пойнтов. На рассмотрение документ был отправлен в компанию где делают портал и вот там на мой план сказали: а где синхронизация тестирования? где описание того, как будет проходит этот процесс, чтобы не осталось ни одного места не покрытого тестами. И вот тут честно, я не понимаю, ведь если с нашей строны все работает, то уж их кнопки тоже должны.
a mozno vot etot moment utochnit’ ? Chochetsia bolshe konkretiki
Подробнее было так: А где описание того, как мы синхронизируем тестирование, чтобы перед сдачей клиенту быть уверенными, что всё работает, что всё покрыто тестами.
Весь покрытый тестами, абсолютно весь
Код в репозитории на Github’е есть…
интересные коллеги у вас
то есть сейчас они не тестируют вообще, а когда вы предлагаете хоть какую-то стратегию, начинают задавать идиотские вопросы?
В этой фразе прекрасно все 
Если весь портал зависит от сервиса, то главное проверить интерфейс, можно использовать автоматизацию веб-интерфейса. Если тесты нашли проблему - выяснять, на какой стороне, и соответственно делать баг. Это собственно и будет синхронизация, на мой взгляд. Также сделать автоматизацию тестов апи. Это поможет проверить, что они дают данные согласно требованиям.
Каждый компонент (BE, FE) тестируется по спекам. REST API должен быть заранее задокументирован и не меняться.
Перед сдачей закладывается время на интеграцию компонентов, здесь должны проводиться какие-то функциональные ui e2e тесты.
Возможно будет возможность интегрироваться поэтапно по фичам, эпикам…
Чем сложнее система, тем всё сложнее…
а эти 2 системы сейчас пишутся с нуля? Если нет, то стоит узнать какой процесс тестирования на данный момент, т.е. как-то это всё работало, наверное, до вас
Как показывает практика, главное договориться о зонах ответственности и процессе, что делать, если на чей-то стороне найдены ошибки, чтобы максимально быстро их устранять и не блокировать другую команду.
В плане тестирования, можно построить так:
-
команда разработчик API тестирует все у себя (как бы понянто и так), также если есть микросервисы и они между собой “общаються” - это тоже тестируют в основном они и автотестами;
-
команда разроботчик портала - у нее все сложнее. Можно договориться брать самые свежие версии кода API или доступ к инстансу где бекенд последней версии и против них проганять небольшой сьют, который проверяет корректность моделей, основных сущостей, обьектов и валидирует что все хорошо. Это может быть простые вызовы с Postman - не true way, или уже сьют на удобном языке с автоматическими тригеррами и репортами, плюс “светофором” чтобы все видели current state. Если что-то падает, сразу информировать команду-разработчика API и для них это должна быть задача “блокер”;
-
еще команде разработчику портала лучше иметь хороший сьют e2e тестов, так как при разработке связанных микросервисов часто бывает, что сервис сам по себе протестирован и в связке с другими вроде хорошо протестирован, но на клиенте “бока”… Сдесь тяжело разорбаться кто виноват и если уверены, что не клиентская часть (портал), то в основном надо “умело” читать логи бекенда и понимать что он делает не так, или иметь человека на другой стороне, чтобы попросить помочь разобраться в проблеме. Опять таки, можно договориться, чтобы такой челевек всегда был, или какой-то общий канал (типа как в Slack) и туда писать о найденых или потенциальных проблемах.
Если плюс-минус такая модель начинает работать, то со временем обьем тестов на обеих сторонах растет, что позволяет быстрее привентировать несовместимости.
Не совсем понимаю о какой синхронизации тестирования идёт речь.
Команда разработки апи и бэка делает свою работу, сама тестирует свой функционал как обычно. И гарантинует, что будет предоставлять рабочий функционал.
Команда пользователь апи тестирует свою логику, и если они решают вам не доверять то сверху ещё могут замазать все е2е или тестами на контракты апи. В зависимости от тех ресурсов которыми они располагают.
Тестироваться вы вообще можете отдельно.
Синхронизировать вас будет версия апи.
На самом деле я не очень понимаю в чём сложность. Скорее всего у вас есть опыт работы в команде которая как получает данные из внешних источников так и обрабатывает их для других пользователей. Используйте его.
Ещё по поводу синхронизации, пусть менеджеры синхронизируют роадмап. И все итак будет хорошо
Возможно вам будет проще если задачу рассматривать не как единое целое. А как две задачи: организовать тестирование в одной команде и организовать тестирование в другой команде.
Для организации независимого контрактного тестирования между сервисами существует специальная библиртека PACT. Реализованна на различных языках програмирования