да, бизнес кейсы он сформулирует, их могу и я сформулировать, но мне не нравистся что это частности нет системности, всё заканчивается предложением тестировать методы на поднятом  приложении с in memory db, самые данные по большому счёту берутся наобум, это будет работать, но не выглядит правильным

Полное покрытые - перебор всех данных. С учетом классов эквивалентности и все такое. Все равно все кейсы ты перебирать не хочешь потому что их много. Значит надо приоритизировать кейсы, так?

да

Ну вот я предлагаю их приоритизировать на основании ценности для бизнеса. Это же не наобум.

Как определить ценность в общем случае я не знаю. Можно хоть логи с прода спарсить

А может есть понимание, что ошибка в каком-то может очень дорого стоить

чтобы приоритизировать нужно выделить категорию в рамках которой приоритизировать иначе не получится сформулировать критерий

что для бизнеса важнее
1) чтобы апишка не падала из-за ошибки во взаимодействии 1 и 2 компонента
2) из-за ошибки в 1 компоненте
3) из-за несоответсвия бекенда базе
4) из-за несоответсвия фронтенда бекенду
5) из-за переполнения инта
6) из-за некооректного перехвата ошибок

это просто разные типы ошибок, мы сначала выбираем тип ошибок
и уже в рамках этого типа начинаем покрывать

бизнес только подскажет с какого раздела лучше начать тестировать, а не с того как начать тестировать

ну опять

бизнес ничего не знает про инты, бекенд и базу

ему пофигу на реализацию

вообще не думай про это

отталкивайтесь от пользовательских кейсов, которые критичны для бизнесы(авторизация/покупка). после пусть представитель бизнеса приоритизирует их, ну а Вы покроете тестами реализацию конкретной функциональности.

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

Уже завтра, в пятницу 13 декабря, cостоится международная онлайн конференция по тестированию QA Z Day 2019 https://community-z.com/events/qa-z-day https://community-z.com/events/qa-z-day  
Ежегодные конференции QA Z Day - это:
-  4 потока
-  40 докладов
-  авторские онлайн мастер-классы
-  материалы только от спикеров-практиков
-  2000+ удаленных участников
Пожалуйста, зарегистрируйтесь, что бы получить линк на online конференцию и последние обновления программы https://community-z.com/events/qa-z-dayhttps://community-z.com/events/qa-z-day

@Dmitry42
я говорю вот об этом, вы хотите чтобы я просто забил на всё кроме функционального и спросил приоритеты у бизнеса, я могу так сделать, но не хочу, я вижу перед собой объёмную классификацию, понимаю что если я забью на это, то словлю проблемы но позже

Всем привет. Пожалуйста подскажите пожалуйста, пишу фичу(сценарий) cucumber, когда запускаю отдельную фичу (правая кнопка мыши и ран) фича запускается и нормально проходит. Но  когда хочу запустить все фичи в TestRunner.Java или же с  команды mvn clean verify serenity:aggregate то все тесты после запуска просто СКИПаются. Ошибок вроде как нет в консоле
http://joxi.ru/8An8lbPHz5ka4m

> Как войти в IT в контексте QA Automation
серьезно?

Так вопрос был про интеграционные тесты и выбор данных для них, а не объяснить чем отличаются разные типы тестирования

Да :) 4 потока, 40 + докладов, разной сложности. А вход в IT с нуля через Автоматизацию - это тренд последние 5 лет, по крайней мере в РБ :) Важно что бы онлайн событие было болезно самому широкому кругу слушателей от QA Manager-ов до самых молодых специалистов.

Если вы упоритесь в покрытие сценариев по всем видам и слоям, у вас закончится время на разработку продукта)
Ответьте в первую очередь на вопрос - какую проблему вы пытаетесь решить. Покрыть все возможные сценарии невозможно. Грамотное использование unit тестов обычно решает 90% проблем при изменении исходников.