Заміняти застарілі вимоги до BDD


11

Питання: Який найкращий спосіб перенести велику компанію в «Огірок», принаймні 15 років застарілих програмних вимог, що зберігаються в базі даних з вимогами?

В даний час розглядає:

1) Мігрувати все

Нижня сторона: у нас немає необмеженого часу / бюджету, ми повинні рухатися вперед, щоб вижити, ми не можемо зупинити все і GC 100% наших вимог у спадщину та наборів для тестування.

2) Хлопське скаутське правило

Залиште все краще, ніж ви знайшли. Якщо ви торкаєтесь вимог або змінюєте їх, напишіть / оновіть функцію огірка. Знизу: у нас буде дві системи запису (Cucumber, legacy req. DB), можливо, навіки припускаючи, що є кути даної програми, які не торкаються дуже довго.

3) Правило скаутського хлопця Плюс

Те саме, що є №2, але висуваємо вимоги, які ми не переходимо на огірок до функцій із єдиним очікуваним сценарієм та копіюємо / вставляємо застарілі вимоги в розділ опису. Таким чином ми отримуємо показники (через очікувані сценарії) щодо того, наскільки ми «охоплені» огірком, а також позбавляємо нас від необхідності підтримувати стару систему вимог. Я не можу знайти жодних недоліків цього, крім того, що це може бути величезним безладом всередині Огірка.

4) Вставте сюди свою ідею.

Фон:

Деякі проекти, що переїжджають до огірків, мають автоматизовані тестові набори, деякі застосовували лише ручне тестування. Усі вони підтримують свої вимоги у базі даних спадкових вимог. Ми повинні це зробити, оскільки наші вимоги - це суміш законів / норм та складної логіки фінансових інструментів (ризик, ціноутворення, структура тощо).

Майте на увазі, що це дуже велика компанія, яка робить хід, що ще більше ускладнює рішення.

У нас вже є кілька проектів, що використовують огірок для їх "нових" вимог. Таким чином, ми пілотували техніку, і це працює для нас поки що. У нас є суміш веб-проектів і суто даних.

Дякую

Редагувати: Щоб відповісти на запитання ... БД управління застарілими вимогами не підключає вимоги до тестів. Це не "перевірено". Сьогодні підключення вимог до тестів здійснюється через важкий ручний процес, пов'язаний з помилками та похибкою, що стосується вимог до нашої системи управління тестовими справами в кінці кожного проекту. Огірок - очевидно краще рішення для нас. Про це не йдеться. Питання полягає лише в тому, як зробити крок для великої організації з величезною кількістю важливих вимог, які не можуть бути втрачені з юридичних та інших причин.


1
+1 за запитання; але в більш загальній обстановці: як перейти від однієї системи тестування до іншої?
Sjoerd Job Postmus

Чи автоматизована база даних "застарілих" вимог щодо перевірки відповідності вимогам? Чи потрібно буде повторно вимовляти слова, щоб відповідати синтаксису огірка (і якщо так: переконайтесь, що переформулювання не змінює вимоги тонко)?
Joe Postbut

Тільки цікавість, чи базується ця база даних вимог? якщо так, то ви можете спробувати автоматизувати процес як варіант №4, зробивши програму, яка читає застарілі тести та намагається написати тест для огірків ВИНАГО, якщо тести не читаються. Маючи два джерела справжнього, як правило, не рекомендується через можливі невідповідності (2 вимоги,
ДБ

1
Ви писали: "Ми пілотували техніку, і це для нас робота поки що", але ви не написали "це працювало краще, ніж попередній тех". Отже, ви на 100% впевнені, що це буде поліпшенням? В іншому випадку найкращим способом може бути не зробити цього ;-)
Док Браун

Відповіді:


8

Я допустив помилку, знімаючи кімнату до шпильки, коли замінював її вікна. Це старий будинок. Кімната була в поганому стані. На кожному кроці по дорозі я стикався з проблемами. У моїй руці кришилася стара труба. Зараз звисаючий двадцять п’ятьфунтовий сантехнічний вентилятор впав і врізався крізь кухонну стелю. (На щастя, ніхто не постраждав, але зарядний мобільний телефон моєї подруги був розбитий. Її не розвеселили.) Я шокував пекло від себе, коли одночасно вдарив об заземлений і незаземлений ланцюг. Була відкрита старовинна електропроводка, що проходить через продувається ізоляцію.

З кожним номером мені довелося перенаправляти свої енергії. Я зупинився, щоб виправити проблему. Потім, іноді днів пізніше, я відновив прогрес вперед. До осені я здався. (Я планував зробити це наприкінці літа.) Я просто зупинився і пішов геть. Це було занадто багато. Моя дівчина хотіла викликати підрядника. Я відмовився, оскільки вже зробив стільки роботи. Я не хотів, щоб вони отримали "славу". (Крім того, я трохи особливий і не хотів, щоб хтось різав кути там, де я знав, що не буду.) Отже, кімната сиділа недобудованою.

Майже рік тому, після Нового року, у мене настала епіфанія: не було жодного правила, яке говорило, що я повинен працювати виключно над кімнатою, поки вона не буде закінчена. Поспіху не було. Мені не довелося робити це так багато. Натомість, якби у мене було трохи вільного часу, я міг би піднятися наверх і провести годину чи дві в кімнаті ... повісити простирадло, грязь і скотч на стіну, обшити двері. Перш ніж я знав це, я закінчив. Моя подруга знову полюбила мене. Я спав із усмішкою на обличчі. У світі все було правильно.

Я думаю, що є щось подібне для вашого важкого становища. Будьте мудрою черепахою - повільною і стійкою. Шлях «Перенести все» занадто напружений. Це змусить вас кинути руки і піти геть. Правило хлопців-скаутів залишає позаду функції, якщо вони ніколи не змінюються. Хлопчикове скаутське правило плюс створює вимоги до номіналу. Використовуйте найкращі підходи:

  1. Якщо ви торкаєтесь вимоги, перенесіть її на Огірок.
  2. Тим часом встановлюйте щотижневу міграційну мету. Робіть трохи щотижня. Не варто робити це все або нічого. Ви можете виявити, що епізодична робота з міграції є приємною відмовою від усіх інших робіт, які ви зробили.

Перш ніж це знати, ви закінчите. Ваш начальник полюбить вас. Ваша команда вас полюбить. Ви будете спати з посмішкою на обличчі.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.