ну а техпис тут при чём?

ПМИ это фактически Acceptance Test Design

ещё можно аналитику и архитектуру разработать — он же требования делал, значит лучше всех понимает, как их реализовать

а потом воют, что аналитику не хватает времени на создание ценности

я про роль "техписа", которая вполне помещается в роль аналитика

стало грустно

ПРОЕКТИРОВАНИЕ приёмочных сценариев — это инженерно-синтетическая работа

а не просто документирование принятых решений, как у техписа

аналитики же в том числе фиксируют договорённости с заказчиком. Не понимаю, почему грустно

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

в общем упрощённый алгоритм такой:

1) выстраиваете юскейсы в последовательную цепочку, например, на основе сквозного бизнес-процесса, CJM или User Story Map
2) выбираете конкретные атрибуты и объекты ввода-вывода, на примере которых хотите проводить приёмку, превращая таким образом юскейсы в тесткейсы

если юскейсов нет, пытаетесь сделать то же самое с последовательностью функций / User Stories

Поняла. Спасибо огромное за помощь. Будем учиться и делать(:

вон англоязычная теория на эту тему https://www.softwaretestinghelp.com/what-is-acceptance-testing/

По мне так ПМИ пишется довольно не сложно.
Берете абзац или предложение из ТЗ и "придумываете" как его проверить

У меня получалось очень похоже на use case только с тестовыми данными )))

Для сокращения количества документов я делал ссылки на руководство пользователя.
Что-то типа - выполните такие-то пункты руководства пользователя с указанием тех-то данных, если результат предпологаемый, тест выполнен, если нет то тест провален )))

спасибо

Всем спасибо 😊

Разный смысл слова “структурный”. Структурное программирование так сильно обогатило профессию программистов, что я не решаюсь привести хотя бы один довод против него. Однако я должен сказать, что структурное программирование — это средство для программирования в небольших размерах. Его помощь при проектировании системы в больших масштабах невелика. Оно делает программирование более наглядным и более управляемым по многим уже перечисленным причинам, но наибольшая помощь оказывается им в проектировании и при собственно программировании.
      Нам следует быть осторожными и не путать методы, применяемые в одном из разделов разработки программного обеспечения, с методами, используемыми в других частях этого процесса. Люди, занимающиеся торговлей программной продукции, приклеивают слово “структурный” к любому применяемому методу. Раз метод “структурный”, товар будет продан.
      Структурное проектирование не имеет ничего общего со структурным программированием. Оно подчиняется законам структурного программирования не в большей степени, чем законам программирования по всем другим методикам.
В моду входит термин “структурные требования”. Он ничего общего не имеет с терминами структурное программирование и структурное проектирование. Сейчас уже появляется структурная документация, структурный английский язык и т.д. и т.п.
      Если мы можем точно определить данный термин, как это сделали для структурного программирования Милс, Лингер и Уитт, то может быть этот термин и окажется полезным. В общем случае, все это отдает торгашеским духом, о чем можно только пожалеть — ведь у метода наверняка есть свои достоинства, просто его не надо называть “структурным”.
      Все это говорится вовсе не для того, чтобы бросить на новые методы тень. Многие методы очень хороши. Но их похожие названия требуют некоторой совместимости, которой на самом деле нет.