Питання: Який найкращий спосіб перенести велику компанію в «Огірок», принаймні 15 років застарілих програмних вимог, що зберігаються в базі даних з вимогами?
В даний час розглядає:
1) Мігрувати все
Нижня сторона: у нас немає необмеженого часу / бюджету, ми повинні рухатися вперед, щоб вижити, ми не можемо зупинити все і GC 100% наших вимог у спадщину та наборів для тестування.
2) Хлопське скаутське правило
Залиште все краще, ніж ви знайшли. Якщо ви торкаєтесь вимог або змінюєте їх, напишіть / оновіть функцію огірка. Знизу: у нас буде дві системи запису (Cucumber, legacy req. DB), можливо, навіки припускаючи, що є кути даної програми, які не торкаються дуже довго.
3) Правило скаутського хлопця Плюс
Те саме, що є №2, але висуваємо вимоги, які ми не переходимо на огірок до функцій із єдиним очікуваним сценарієм та копіюємо / вставляємо застарілі вимоги в розділ опису. Таким чином ми отримуємо показники (через очікувані сценарії) щодо того, наскільки ми «охоплені» огірком, а також позбавляємо нас від необхідності підтримувати стару систему вимог. Я не можу знайти жодних недоліків цього, крім того, що це може бути величезним безладом всередині Огірка.
4) Вставте сюди свою ідею.
Фон:
Деякі проекти, що переїжджають до огірків, мають автоматизовані тестові набори, деякі застосовували лише ручне тестування. Усі вони підтримують свої вимоги у базі даних спадкових вимог. Ми повинні це зробити, оскільки наші вимоги - це суміш законів / норм та складної логіки фінансових інструментів (ризик, ціноутворення, структура тощо).
Майте на увазі, що це дуже велика компанія, яка робить хід, що ще більше ускладнює рішення.
У нас вже є кілька проектів, що використовують огірок для їх "нових" вимог. Таким чином, ми пілотували техніку, і це працює для нас поки що. У нас є суміш веб-проектів і суто даних.
Дякую
Редагувати: Щоб відповісти на запитання ... БД управління застарілими вимогами не підключає вимоги до тестів. Це не "перевірено". Сьогодні підключення вимог до тестів здійснюється через важкий ручний процес, пов'язаний з помилками та похибкою, що стосується вимог до нашої системи управління тестовими справами в кінці кожного проекту. Огірок - очевидно краще рішення для нас. Про це не йдеться. Питання полягає лише в тому, як зробити крок для великої організації з величезною кількістю важливих вимог, які не можуть бути втрачені з юридичних та інших причин.