Звучит как системный подход к работе с требованиями. Круто!
Поделюсь что у нас. Для сбора контекста всех заинтересованных сторон мы используем "3-амиго". Что касается архитектурных решений, локальные технические решения могут быть прямо в спецификациях, а решения более низкого уровня проходят процедуру TDR и хранятся в общем хранилище.
Тесты дают некоторую гарантию соответствия спецификации (функциональность работает согласно требованиям). Про управление знаниями согласен и зрелого решения я тоже ещё не встречал.
Спасибо за уточнение, да, такое конечно возможно, но измерения мы не проводили. Если у вас есть методология, буду раз если поделитесь. Избежать дрифта помогают детерминированные тесты в коде: юнит, интеграционные, E2E, авто и ручные.
Упрощенно работает примерно так: продакт-менеджеры описывают эпики и задачи на естественном языке в удобном виде, как правило, это jira + confluence. Проводится встреча 3-амиго. ИИ-агент делает анализ всех артефактов и оценивает полноту и достаточность юзер-стори и критериев приемки, задает вопросы и потом генерирует структурированный spec.md, который лежит в репозитории с кодом. Во время реализации могут появиться расхождения относительно изначальной спецификации по инициативе команды, поэтому есть шаг, когда после завершения работы агент вносит правки в спецификацию, поэтому расхождения минимальны. Надеюсь, я верно понял термин "дрифт спеки", если нет, уточните вопрос, пожалуйста.
Как вариант, можно было заглянуть в консоль разработчика, посмотреть какой API запрос шлёт фронт беку после заполнения опроса и не заморачиваться с Selenium.
Звучит как системный подход к работе с требованиями. Круто!
Поделюсь что у нас. Для сбора контекста всех заинтересованных сторон мы используем "3-амиго". Что касается архитектурных решений, локальные технические решения могут быть прямо в спецификациях, а решения более низкого уровня проходят процедуру TDR и хранятся в общем хранилище.
Тесты дают некоторую гарантию соответствия спецификации (функциональность работает согласно требованиям). Про управление знаниями согласен и зрелого решения я тоже ещё не встречал.
Спасибо за уточнение, да, такое конечно возможно, но измерения мы не проводили. Если у вас есть методология, буду раз если поделитесь. Избежать дрифта помогают детерминированные тесты в коде: юнит, интеграционные, E2E, авто и ручные.
"Не читал, но осуждаю" (С) :)
Спасибо за комментарий, конечно можно делать всё самому, по старинке, но технология ИИ-агентов дает возможность ускорить и удешевить разработку ПО.
Упрощенно работает примерно так: продакт-менеджеры описывают эпики и задачи на естественном языке в удобном виде, как правило, это jira + confluence. Проводится встреча 3-амиго. ИИ-агент делает анализ всех артефактов и оценивает полноту и достаточность юзер-стори и критериев приемки, задает вопросы и потом генерирует структурированный spec.md, который лежит в репозитории с кодом. Во время реализации могут появиться расхождения относительно изначальной спецификации по инициативе команды, поэтому есть шаг, когда после завершения работы агент вносит правки в спецификацию, поэтому расхождения минимальны. Надеюсь, я верно понял термин "дрифт спеки", если нет, уточните вопрос, пожалуйста.
Спасибо за отличное саммари! Формула, на самом деле, немного сложнее и кастомизируется под контекст проекта, но как базу можно брать смело.
Спасибо! :)
Привет! Известный факт, что тесты могут сразу не заработать или поломаться и будет требоваться отладка, как она происходит с использованием emcee?
А как обстоят дела с HTTP версий 2 и 3? Или это ждать в новых частях статьи?
Как вариант, можно было заглянуть в консоль разработчика, посмотреть какой API запрос шлёт фронт беку после заполнения опроса и не заморачиваться с Selenium.
Спасибо за интересную статью! Меня впечатлила ваша находчивость и энтузиазм. Особенно, история про отправку резюме "сверху".
Тесты могут жить на windows, а Selenoid на отдельной машине с Linux, на которой запускаются контейнеры с браузером.