Вопрос: Каков наилучший способ перевести крупную компанию в Cucumber, если в базе данных требований хранятся не менее 15 лет устаревших требований к программному обеспечению?
В настоящее время рассматриваются:
1) все переносить
Недостаток: у нас нет неограниченного времени / бюджета, нам нужно двигаться вперед, чтобы выжить, мы не можем все остановить и соблюдаем 100% наших устаревших требований и устаревших тестовых наборов.
2) Правило бойскаута
Оставь все лучше, чем ты нашел. Если вы касаетесь требований или меняете их, напишите / обновите функцию Cucumber. Недостаток: у нас будет две системы записи (Cucumber, устаревшая версия DB), возможно, навсегда предполагая, что есть углы данного приложения, которые не затрагиваются в течение очень долгого времени.
3) Бойскаут Правило Плюс
То же, что и № 2, но мы добавили требования, которые мы не переходим в Cucumber, в компоненты с одним ожидающим сценарием и скопируйте / вставьте устаревшие требования в раздел описания. Таким образом, мы получаем метрики (в ожидающих сценариях) о том, насколько «покрыты» мы Cucumber, а также о необходимости поддерживать старую систему требований. Я не могу найти никаких минусов в этом, кроме как может быть огромный беспорядок в огурце.
4) Вставьте свою идею здесь.
Фон:
Некоторые проекты, перемещающиеся в Cucumber, имеют автоматизированные тестовые наборы, а некоторые используют только ручное тестирование. Все они поддерживают свои требования в устаревшей базе данных требований. Мы должны сделать это, потому что наши требования представляют собой смесь законов / регулирования и сложной логики для финансовых инструментов (риск, ценообразование, структура и т. Д.).
Имейте в виду, что это очень большая компания, которая делает этот шаг, что еще больше усложняет решение.
У нас уже есть несколько проектов, использующих Cucumber для их «новых» требований. Итак, мы опробовали технологию, и она пока работает для нас. У нас есть смесь веб-проектов и проектов данных.
благодаря
Изменить: Чтобы ответить на вопросы ... Устаревшая база данных управления требованиями не связывает требования с тестами. Это не "тестируемый". Сегодня подключение требований к тестам осуществляется через сложный и подверженный ошибкам ручной процесс привязки требований к нашей системе управления тестовыми сценариями в конце каждого проекта. Огурец - очевидное лучшее решение для нас. Там нет вопроса об этом. Вопрос только в том, как сделать шаг для большой организации с огромным количеством важных требований, которые не могут быть потеряны по юридическим и другим причинам.