Ну а вот эта часть уходит в исследовательское тестирование, которое ручное, это да

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

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

Не выходит. Ну разве что, если пожелать недостаточное покрытие.

Ну да. Это же логично выносить всю бизнес логику в ручное исследовательское тестирование.

Всё так.

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

Я такого не говорил 🤷🏻‍♂️

> делается тест-дизайн на основе модели (используется сваггер или UI мокапы) + учитываются требования (используются требования к веб-сервису или системе в целом)

Ну в общем я лично работал по такому процессу на очень успешном проекте в предыдущей компании и сейчас в новом проекте пытаюсь повторить трюк

Это так не работает, к сожалению. Там дело в том, что количество позитивных кейсов конечно и теоретически их можно написать и заскриптовать. А вот количество проблем, которые могут возникнуть бесконечно или близко к этому.

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

Картинки нельзя постить) тут примерно начиная с 11:30

Ну и вот например этот практически целиком: https://youtu.be/IKx5xTtR1pU

Спасибо, что не болтон😁

Как я говорил, на моём проекте такой процесс работал и за 2 года на продакшене обнаружился примерно один баг.
При этом я видел (и иногда участвовал) десятки проектов, где мануальное и автоматизированное тестирование были четко выделены и разделены по времени, но продукт был полон багов.
Так что тут есть 2 поинта.
Во-первых, тестирование изначально не гарантирует отсутствие багов и никакой процесс не может это изменить. Поэтому нужно оценивать риски и стоимость обнаружения бага в проде и планировать стратегию исходя из этого. Я не предлагаю ATDD как лекарство от всех болезней. Но от большинства из них оно поможет)
Во-вторых, если у тестировщиков низкий уровень, то они накосячят в любом процессе. По моему опыту, команда из 10 ручных тестировщиц и 5 автотестеров не даёт никаких гарантий и прозрачности. Скорее наоборот, увеличивает хаос и перекладывает ответственность, из чего следует большое количество пропущенных багов. А координация этого цирка - отдельный круг ада

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

Поэтому если топикстартеру начальство само предлагает такой процесс, то оно более-менее осознаёт риски и преимущества такого подхода, и они всех устраивают

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

Соглашусь. Панацеи нет. Результат сильнее зависит от квалификации участников, чем от всех методик вместе и по одиночке. Об этом нам еще Крылов, задолго до Болтона, в Квартете рассказал.

Впрочем у квалифицированных участников методы в среднем лучше)

Всем привет, есть кто в вугене юзал java over http , например посылал json используя этот тип проекта ?)