Организация тестирования разделенного бэкэнда и фронтэнда
#1
Отправлено 06 июня 2019 - 07:42
#2
Отправлено 06 июня 2019 - 08:17
общее тестирование нужно чтобы удостовериться что фронт работает с бэком
например Вы протестировали что энд-пойнт принимает 2 параметра
а тестировщик фронта протестировал что их фронт посылает 3 параметра на замоканный бэк
или Вы протестировали что энд-пойнт изменения статуса работает правильно
а на фронте вообще забыли ту кнопку для изменения статуса добавить
в итоге "всё у всех работает", но когда фронт и бэк поставят вместе - работать не будет
"как сделать общее тестирование" - запустить бэк и фронт вместе, тестировать по требованиям к системе
#3
Отправлено 06 июня 2019 - 08:26
Какой интересный кейс. А что у вас прописано в ПМИ?
#4
Отправлено 06 июня 2019 - 08:28
Какой интересный кейс. А что у вас прописано в ПМИ?
совершенно обычный кейс, так же как и например как двигатель и кузов автомобиля делается в разных компаниях
а ПМИ и необязательно для всех
#5
Отправлено 06 июня 2019 - 08:33
общее тестирование нужно чтобы удостовериться что фронт работает с бэком
например Вы протестировали что энд-пойнт принимает 2 параметра
а тестировщик фронта протестировал что их фронт посылает 3 параметра на замоканный бэк
или Вы протестировали что энд-пойнт изменения статуса работает правильно
а на фронте вообще забыли ту кнопку для изменения статуса добавить
в итоге "всё у всех работает", но когда фронт и бэк поставят вместе - работать не будет
Так, ну если исходить из примера про кнопку, и чтобы такого не произошло, тогда нам надо как-то тест кейсами обмениваться?
#6
Отправлено 06 июня 2019 - 08:38
Какой интересный кейс. А что у вас прописано в ПМИ?
у нас его нет.
#7
Отправлено 06 июня 2019 - 08:49
Какой интересный кейс. А что у вас прописано в ПМИ?
совершенно обычный кейс, так же как и например как двигатель и кузов автомобиля делается в разных компаниях
а ПМИ и необязательно для всех
Госучереждение и без ПМИ? Даже не знаю кто в этой ситуации больший идиот заказчик или подрядчик.
Мой вопрос о том, что конкретно заказали и кто ответственен за интеграцию.
Если вы покупаете отдельно кузов и отдельно двигатель, то собрать их в автомобиль - ваша забота. И если одно не лезет в другое - ваша проблема. Не говоря уже о таких мелочах, что юридически ваш конструктор никогда не станет автомобилем, на учет вы его не поставите и ездить сможете только вокруг своего гаража.
#8
Отправлено 06 июня 2019 - 09:30
Какой интересный кейс. А что у вас прописано в ПМИ?
у нас его нет.
Тогда вам нужно объединятся с вторым подрядчиком, обеспечивать им доставку бэкенда на тестовый стенд и отчета о работоспособности бэкенда.
Вашему коллеге, по идее, нужна оперативная информация когда ожидается очередной инкремент по бэкенду, что в нем будет, факт установки его на бэкенд и ваш отчет по тестированию. ну и доступ к вашим тест-кейсам, чтобы он понимал что вы протестировали.
#9
Отправлено 06 июня 2019 - 09:39
Вам нужна общая интеграция. Без этого две части программы могут работать раздельно, а вместе вряд ли)
#10
Отправлено 06 июня 2019 - 10:15
Да, интересная продажа слона по частям...))
Вам нужна общая интеграция. Без этого две части программы могут работать раздельно, а вместе вряд ли)
#11
Отправлено 06 июня 2019 - 10:53
Да, интересная продажа слона по частям...))
Вам нужна общая интеграция. Без этого две части программы могут работать раздельно, а вместе вряд ли)
Я уже тогда совсем запуталась. На англоязычных сайтах пишут, что микросервисы тем и хороши, что можно менять что код фронта, что энда и все равно система будет работать. По вашим комментам, что общая интеграция нужна.Как тогда быть? Предложить Jira, я тестирую свои кейсы, другой тестировщик пишет под них свои тесты?
Микросервисы хороши тем, что не позволяют нахерачить сильно связанный код. Импакт изменений получается ограничен микросервисом и его клиентами, что резко уменьшает объем регрессионного тестирования. Но не отменяет интергационного тестирования.
Следующим шагом на пути уменьшения количества тестирования является контрактное тестирование, когда составляется очень строгое формальное описание АПИ - контракт и клиенты и сервисы очень строго проверяются на соблюдение этого контракта. Такое тестирование имеет смысл когда вы не можете контролировать появление новых и изменение старых клиентов вашего сервиса
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных