Q : 요구 사항 데이터베이스에서 15 년 이상의 레거시 소프트웨어 요구 사항을 유지하면서 대기업을 Cucumber로 이전하는 가장 좋은 방법은 무엇입니까?
현재 고려중인 사항 :
1) 모든 것을 마이그레이션
단점 : 우리는 무제한 시간 / 예산이 없으며 생존을 위해 앞으로 나아가 야하며 모든 것을 막을 수는 없으며 레거시 요구 사항 및 레거시 테스트 스위트의 100 %를 모두 막을 수는 없습니다.
2) 보이 스카우트 규칙
당신이 찾은 것보다 더 나은 모든 것을 남겨주세요. 요구 사항을 터치하거나 변경하면 Cucumber 기능을 작성 / 업데이트하십시오. 단점 : 우리는 두 개의 기록 시스템 (Cucumber, legacy req. DB)을 갖게 될 것입니다. 아마도 오랫동안 응용되지 않은 주어진 응용 프로그램의 모서리가 있다고 가정 할 것입니다.
3) 보이 스카우트 규칙 플러스
# 2와 동일하지만 보류중인 단일 시나리오를 통해 오이로 순 이동하지 않는 요구 사항을 기능에 넣고 레거시 요구 사항을 설명 섹션에 복사 / 붙여 넣습니다. 이러한 방식으로 우리는 Cucumber가 어떻게 "보장"했는지에 대한 메트릭을 보류중인 시나리오를 통해 얻을 수 있으며 기존 요구 사항 시스템을 유지해야 할 필요성을 극복 할 수 있습니다. 오이 내에서 큰 혼란이 될 수있는 것 이외의 다른 단점은 없습니다.
4) 여기에 아이디어를 삽입하십시오.
배경:
Cucumber로 이전하는 일부 프로젝트에는 자동화 된 테스트 스위트가 있으며 일부는 수동 테스트 만 사용했습니다. 모두 레거시 요구 사항 데이터베이스에서 요구 사항을 유지 관리합니다. 우리의 요구 사항은 법률 / 규제와 금융 상품에 대한 복잡한 논리 (위험, 가격, 구조 등)가 혼합되어 있기 때문에이를 수행해야합니다.
이동이 매우 큰 회사이므로 솔루션이 더 복잡해집니다.
우리는 이미 "새로운"요구 사항으로 Cucumber를 사용하는 프로젝트를 가지고 있습니다. 그래서 우리는 기술을 시험해 보았으며 지금까지 우리를 위해 일하고 있습니다. 웹과 순수한 데이터 프로젝트가 혼합되어 있습니다.
감사
편집 : 질문에 응답하려면 ... 레거시 요구 사항 관리 DB는 요구 사항을 테스트에 연결하지 않습니다. "테스트 가능"하지 않습니다. 오늘날 요구 사항을 테스트에 연결하는 것은 각 프로젝트가 끝날 때 테스트 케이스 관리 시스템에 요구 사항을 연결하는 까다 롭고 오류가 발생하기 쉬운 수동 프로세스를 통해 수행됩니다. 오이는 우리에게 더 나은 솔루션입니다. 그것에 대해 의문의 여지가 없습니다. 문제는 법적 및 기타 이유로 잃어 버릴 수없는 방대한 양의 중요한 요구 사항을 갖춘 대규모 조직으로 전환하는 방법입니다.