testomat.io управление авто тестамиВопрос наверное не по теме, но. Вас назначили ответственным за организацию тестирования и обеспечения качества в весьма сложном проекте и при этом вы никогда ни с чем подобным не сталкивались?
Да так и есть. Я всегда был ответственнен за проекты внутри компании, но теперь достался такой проект с микросервисами, с которыми впервые сталкиваюсь и если учесть, что в другой компании только один тестировщик, то всё поручили мне. И чем больше я читаю про тестирование микросервисов, тем больше возникает вопросов.
хех, м-да, ну и ушлый же у вас работодатель. Не представляю, как один человек может организовать тестирование на всех уровнях, не будучи десижн-мейкером и не имея опыта. На вашем месте плюнул бы на это слюной и отправился бы в компанию, где можно поучиться и увидеть как это делается. Не думаю, что здесь кто-то сможет дать исчерпывающий ответ на вопрос, который требует от исполнителя несколько лет опыта и высокой квалификации.
7 лайков
Не думаю, что прям так всё критично, чтобы увольняться. + Я не прошу сделать всё за меня, а лишь дать наводки. Может кто-то из пользователей был в таком проекте и сможет посоветовать. Может есть какой другой форум, где можно спросить у тех, кто в этой теме
3 лайка
На вас хотят ездить, а вы говорите что это не так критично.
Тут два варианта - просить прибавку к ЗП, либо сруливать.
А по факту - тестирование ядря должно покрываться компанией, которая ведёт разработку ядра.
Что именно вы хотите просинхронить?
Со стороны графического интерфейса это уже будет просто проверка то что кнопочки работают.
2 лайка
подобный вопрос уже был, где в комментариях был описан подход
1 лайк
Ядро разрабатывает моя компания. План я сделал: юнит, интегрейшн тесты, документация API в swagger и там же тестирования енд пойнтов. На рассмотрение документ был отправлен в компанию где делают портал и вот там на мой план сказали: а где синхронизация тестирования? где описание того, как будет проходит этот процесс, чтобы не осталось ни одного места не покрытого тестами. И вот тут честно, я не понимаю, ведь если с нашей строны все работает, то уж их кнопки тоже должны.
a mozno vot etot moment utochnit’ ? Chochetsia bolshe konkretiki
Подробнее было так: А где описание того, как мы синхронизируем тестирование, чтобы перед сдачей клиенту быть уверенными, что всё работает, что всё покрыто тестами.
Весь покрытый тестами, абсолютно весь
Код в репозитории на Github’е есть…
2 лайка
интересные коллеги у вас
то есть сейчас они не тестируют вообще, а когда вы предлагаете хоть какую-то стратегию, начинают задавать идиотские вопросы?
В этой фразе прекрасно все 
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 лайка
Добро пожаловать в боль распределенных команд и роли тестировщика в них.
Если есть возможность то лучше тестирование Бек, АПИ и ЮИ сервисов выполнять одной общей командой тестировщиков (тогда тестировщики будут знать всю систему в целом и знать на что влияет каждое изменение в каждой из частей распределенного сервиса)
Как может быть в идеальном мире:
-
Бек (ядро)
1.1. Юнит тесты - команды девелоперов (покрытие ± 90%)
1.2. Функциональные тесты, тесты приёма, преобразования и сохранения данных - команда тестировщиков (можно вручную)
1.3. Функциональные тесты АПИ интерфейсов - команда тестировщиков (покрытие 100%) обязательно автоматизировать (очень желательно функциональное тестирование, а не только контрактное, поскольку разработчики очень часто любят зашивать всю бизнес логику на этом уровне) -
Клиенты (мобильные, веб и т.п. )
2.1. Юнит тесты - команды девелоперов (покрытие ± 90%) - заглушки на основании Вашей Swagger схемы (Настройте Faker так чтобы он сам всегда читал обновленный (свежий) свагер от Бека и заполнял все поля необходимыми данными) (Это Ваша первая линия защиты интеграции кода распределенных команд)
2.2. Функциональные тесты, юзер стори, тесты приёма, преобразования данных для передачи посредством АПИ (можно вручную) - команда тестировщиков
2.3. Автоматизированые тесты ЮИ интерфейсов (с замоканым АПИ) - команда тестировщиков (покрытие до 90% счасливых юзер стори, 20-30% - основных обработчиков ошибок)
2.4. Автоматизированые тесты Е2Е - команда тестировщиков (покрытие - только основные счасливые юзер стори те которые являются рисковыми и могут негативно повлиять на бизнес процессы. Пишите здесь только то что действительно важно их прийдется пускать часто и они должны проходить за вразумительное время) (Это Ваша вторая линия защиты интеграции кода распределенных команд) -
Поддкерживающие тесты:
3.1. Бек (ядро) - нагрузочные (Базы данных) - команда девелоперов (автоматизированые)
3.2. Бек (ядро) - нагрузочные (АПИ) - команда тестировщиков (автоматизированые)
3.3. Бек (ядро) - уровни доступа юзер ролей (АПИ) - команда тестировщиков (автоматизированые)
3.4. Клиенты (мобильные, веб и т.п. ) - уровни доступа юзер ролей - команда тестировщиков (автоматизированые) (Это Ваша третья линия защиты интеграции кода распределенных команд)
3.5. Тестирование связаное с изменением инфраструктуры, кластеризация, смены БД или ЯП, обновление версий - команда тестировщиков (тут в основном ручками, желательно иметь в помощь толкового девопса)
Ну и конечно нужно расписать процессы релизов и сборок, для разных команд. Тестовые связки желательно держать вместе.
Я не знаю обьемов Вашего приложения и количества разработчиков каждой из команд, но мне почемуто кажется ту работы явно не на одного двух тестировщиков. Желательно держать отдельную команду тестировщиков в связке с девопсами, ну либо Вам самим прийдется обслуживать тестовые связки, а как показывает практика там бывает такой зоопарк БД и технологий что самим тестировщикам очень тяжело будет справится, особенно если системы будут требовать кластеров и их тонких настроек.
4 лайка