개인 공부를 위해 https://www.geeksforgeeks.org/behavioral-driven-development-bdd-in-software-engineering/를 번역한 글입니다.
오역 의역 있을 수 있습니다.
원본 링크는 글 최하단에 기재해 놓았습니다.
행동 주도 개발(BDD)는 개발자, 테스터, 그리고 비개발직 이해관계자들 고객 중심적인 통합을 하는 것을 우선시하는 애자일 소프트웨어 개발 방법론입니다. BDD에서, 요구사항은 비즈니스 가치를 가져오는 것에 집중하는 더 명확한 의사소통을 가능하게 만드는 기대 행동과 사용자 스토리로 정의됩니다.
목차
이러한 접근법은 문서화와 테스트 역할을 동시에 하는 실행 가능한 명세를 작성하는데 중점을 두며, 프로젝트 목표에 대한 공동의 이해를 촉진하고 제품 품질을 향상시킵니다.
BDD 접근법이 뭔가요?
BDD에서, 팀은 밀접하게 협력하고 각자의 역할을 탐색합니다. 비즈니스 팀은 사용자가 무엇을 경험하기를 원하는지에 기반한 연극 대본(요구사항)을 작성하는 작가와 같습니다. 개발팀은 소프트웨어를 구현함으로써 대본을 삶으로 가져오는 배우와 같은 역할입니다. 그 동안에, QA 팀은 배우의 역할을 관찰하며 계획한대로 연극이 흘러가는 것을 보장하는 감독 역할을 합니다.
BDD라는 대본은 "Given", "When", "Then" 이라는 간단한 문구를 사용해 소프트웨어의 예상 행동를 나타내는 Gherkin 이라는 문법에 의해 작성됩니다. 예를 들어, 시나리오는 다음과 같이 작성되어야 합니다. "(Given) 사용자가 로그인 했다면, (When) 사용자가 로그아웃 버튼을 클릭했을 때, (Then) 로그아웃 되고 로그인 페이지로 이동 되어야 한다." 이 대본은 이후 소프트웨어가 예상대로 동작하는지 검증하는 자동화된 테스트로 번역됩니다.
BDD를 효과적으로 만드는 것은 프로젝트에 참여하는 모든 사람들이 최종 목표물을 이해하고 동의하는 것을 보장하고, 모두가 프로젝트에 참여하도록 하는 것입니다. 이 공동의 이해는 의사소통 오류와 불일치를 줄여 프로젝트 성공으로 이끕니다.
행동 주도 개발이란게 뭔가요?
행동 주도 개발(BDD)는 TDD 방법론에서 유래된 애자일 소프트웨어 개발을 의미합니다. BDD는 시스템의 행동을 설명하는 테스트로 간주됩니다. BDD는 개발에 속해있는 모든 구성원들이 시스템의 행동에 대한 명확성을 가질 수 있도록 대화를 장려하고 간단한 언어로 구체적인 예시를 보여줍니다. 개발에서 기술은 시스템의 동작을 기반으로 기능을 개발하는 다양한 방법을 정의하며, 이러한 기술은 TDD(테스트 주도 개발)와 DDD(도메인 주도 개발)를 결합합니다.
행동 주도 개발은 코드 구현보다 시스템의 행동에 더 초점을 맞추고 있기 때문에 자동화된 테스트에서의 좋은 접근법입니다. BDD는 시스템의 행동과 시스템의 예상 결과를 자연어를 통해서 표현하도록 합니다. BDD에서 고객, 개발자, 테스터, 이해 관계자와 같은 모든 담당자들은 공동의 대화와 시스템 행동의 설명에 참여합니다.
BDD의 장점
BDD는 몇몇개의 장점을 제공합니다.
1강화된 통합: BDD는 비즈니스 이해관계자, 개발자, 그리고 테스터들이 요구사항을 설명할 때 동일한 언어를 사용하도록 해 화합하도록 합니다. 이것은 팀 멤버들 간의 조화와 더 나은 이해를 촉진합니다.
2명확한 요구사항: Gherkin 문법을 사용해 작성된 테스트 시나리오의 간단한 작성은 요구사항과 기대사항을 명확히하는 것을 돕습니다. 모호함을 줄이고 모든 사람이 기대 행동에 대한 공유된 이해를 가질 수 있도록 합니다.
3사용자 행동에 집중: BDD는 사용자 관점에서의 시스템 행동을 강조합니다. 사용자의 스토리와 시나리오에 집중함으로써, BDD는 개발 공수가 사용자의 요구사항과 우선순위에 맞춰져있도록 보장합니다.
4빠른 이슈 감지: BDD는 개발 과정중에 팀이 잠재적인 이슈를 일찍 파악할 수 있도록, 구현 전에 테스트를 작성하도록 합니다. 이것은 빠른 피드백 순환을 이끌고, 나중에 결함을 수정하는 비용을 줄이도록 해줍니다.
5자동화된 테스트: BDD 시나리오는 Cucumber나 SpecFlow와 같은 도구를 이용해 자동화될 수 있습니다. 자동화된 테스트는 팀이 회귀 검사를 빠르게 하고 지속적인 품질을 보장하도록 해줌으로써 어플리케이션 행동에 빠르고 유용한 피드백을 제공합니다.
6개선된 문서: BDD 시나리오는 시스템 행동에 대한 실행가능한 문서를 제공합니다. 이 문서는 테스트가 정기적으로 실행될때마다 최신으로 유지되며, 소프트웨어에 대한 실시간 명세를 제공합니다.
7더 나은 코드 퀄리티: BDD는 시나리오에 작선된 행동을 준수하는 테스트 가능하고 모듈화된 코드를 장려합니다. 이는 더 적은 결함과 더 쉬운 유지보수가 가능한 더 잘 설계된 소프트웨어를 이끕니다.
전반적으로, BDD는 소프트웨어 개발 라이프사이클 전반에 걸쳐 통합, 명확성, 품질을 이끌어내 더 효과적이고 성공적인 프로젝트를 낳습니다.
BDD의 한계점
BDD는 다음의 몇가지 한계점을 가지고 있습니다.
1초반 학습 곡선: BDD를 받아들이려면 팀이 새로운 프레임워크, 도구 그리고 방법론을 배워야만 하기에, 팀 멤버들이 새로운 방법론에 익숙해질때까지 개발 프로세스는 늦춰질 수 밖에 없습니다.
2시간이 소요되는 작업: 기능 파일을 작성하고, 시나리오를 정의하고, 단계 정의를 관리하는 것은 시간이 소요되는 일입니다. 특히 크고 복잡한 프로젝트일수록 완성까지의 잠재적인 지연이 발생합니다.
3이해관계자의 참여에 의존적: BDD는 비즈니스 분석가, 개발자, 테스터, 그리고 오너를 포함한 모든 이해관계자들의 통합에 의존적입니다. 이해관계자들의 활발한 참여가 없다면 BDD의 효율성이 저하될 수 있습니다.
4복잡한 시나리오에서의 어려움: BDD는 간단한 시나리오의 동작을 잡아내는데 탁월합니다. 하지만 매우 복잡한 시나리오나 극단적인 경우를 다루기에 어려움을 겪으며, 테스트 자동화에서 모호함과 비효율을 초래할 수 있습니다.
5관리 비용 증가: 프로젝트가 커지면서, 존재하는 기능파일에 대한 관리와 업데이트, 요구사항이나 기능의 변경을 반영 단계 정의는 어렵고 공수가 많이 드는 일이 될 수 있습니다.
6오버 엔지니어링 가능성: 적절한 가이드와 감시가 없다면 팀은 불필요한 복잡성을 추가하고 장기적인 유지보수성을 낮추면서 BDD 테스트를 과하게 향상시킬 수 있습니다.
7도구 제한: BDD의 효율성은 지원하는 도구와 프레임워크의 가용성과 적합성에 매우 의존적입니다. 제한된 도구 선택과 현재의 시스템과의 호환성 문제는 BDD의 적용과 구현을 방해할 수 있습니다.
BDD 도구와 프레임워크들
BDD 도구와 프레임워크들은 개발자와 QA 엔지니어, 비즈니스 이해관계자간의 통합을 가능하게 해 BDD 구현을 가능하게 합니다. 다음은 유명한 BDD 도구와 프레임워크 몇개입니다.
1Cucumber: Cucumber는 Ruby, Java, JavaScript, 그리고 그 외 등등 다양한 프로그래밍 언어를 지원하는 널리 사용되는 BDD 도구입니다. Gherkin 문법을 사용한 간단한 글을 이용해 실행가능한 명세서를 작성하게끔 해주고, 단계정의를 자동화할 수 있게 해줍니다.
2SpecFlow: SpecFlow는 .NET 애플리케이션을 위한 BDD 프레임워크로, 주로 C#과 함께 사용됩니다. Visual Studio와 완벽하게 통합되며, 팀이 Gherkin 구문을 사용하여 동작 사양을 정의하고 실행할 수 있도록 합니다.
3Behave: Behave는 Cucumber에서 영감을 받은 Python BDD 프레임워크입니다. 이를 통해 팀은 Gherkin 구문으로 동작 사양을 작성하고 Python의 unittest 프레임워크를 사용하여 실행할 수 있습니다.
4JBehave: JBehave는 Gherkin 구문으로 작성된 동작 사양의 실행을 지원하는 Java 기반 BDD 프레임워크입니다. JUnit 및 TestNG와 같은 인기 있는 Java 테스트 프레임워크와 통합됩니다.
5RSpec: RSpec은 Ruby 애플리케이션을 위한 BDD 프레임워크입니다. 개발자는 "describe" 및 "it" 블록이라는 설명적 구문을 사용하여 동작 사양을 정의할 수 있으므로 실행 가능한 사양을 작성하는 데 도움이 됩니다.
6Robot Framework: Robot Framework는 BDD 관행을 지원하는 일반적인 테스트 자동화 프레임워크입니다. 이를 통해 팀은 키워드 기반 구문을 사용하여 동작 기반 테스트 사례를 작성할 수 있으며 다양한 외부 라이브러리 및 도구와의 통합을 지원합니다.
7Karate: Karate는 API 테스트를 위한 오픈소스 BDD 프레임워크입니다. 이를 통해 팀은 Gherkin 구문으로 API 테스트를 작성하고 내장 HTTP 클라이언트를 사용하여 실행할 수 있습니다. Karate는 또한 데이터 기반 테스트, 모의 및 병렬 실행을 위한 기능을 제공합니다.
8Gauge: Gauge는 Java, C#, Ruby, Python, JavaScript를 포함한 여러 프로그래밍 언어를 지원하는 가볍고 크로스 플랫폼 BDD 프레임워크입니다. 이를 통해 팀은 Markdown을 사용하여 실행 가능한 사양을 작성하고 "플러그인"이라는 플러그인을 사용하여 자동화할 수 있습니다.
이러한 도구와 프레임워크들은 팀이 BDD를 효율적으로 구현하게끔 해주며, 통합을 촉진시키고, 대화를 권장하며, 높은 품질의 소프트웨어 제품을 제공하게 도와줍니다.
BDD 모범 사례
BDD를 사용할 때에는, 아래의 몇가지 핵심 사례를 따르는 것이 중요합니다.
1일찍 시작하기: 소프트웨어 행동을 정의하고 잠재적인 이슈들을 예측하기 위해 당신의 테스트 시나리오를 빨리 작성하세요. 이건 당신이 여행을 떠나기전에 시간을 아끼고 나중에 일어날 문제를 줄이기 위해 계획을 세우는 것과 비슷합니다.
2한 시나리오당 하나의 행동: 각각의 시나리오들이 하나의 행동에 집중하도록 하세요. 이건 완벽을 기하기 위해 한 접시에 하나의 요리만 올리는 것과 비슷합니다. 시나리오를 이해하고 관리하기 더 쉽게 만들어줄겁니다.
3공통 단계 설정: 만약 각 시나리오마다 특정 단계가 반복된다면, 효율성과 명확성을 위해 공통 단계에 집어 넣으세요.
4재사용 단계: 다른 시나리오에서 반복적으로 사용되는 단계 정의를 재사용해서 시간을 아끼세요.
5데이터 테이블과 개요: 거대한 데이터셋을 다룰때에는, 명확성과 정리를 위해 데이터 테이블과 시나리오 개요를 사용하세요.
6태그: 냉장고의 음식들에 라벨링을 해 쉽게 꺼낼 수 있게 하는 것처럼, 시나리오를 특정 그룹으로 묶어 정리하기 위해 태그를 사용해보세요.
7선언적 글쓰기: 시나리오를 작성할때 너무 기술적인 언어로 쓰려 하지 말고, 사용자가 묘사하는 것과 흡사하게 작성하세요.
8좋은 문법: 혼란을 피하고 이해를 돕기 위해 올바른 문법과 스펠링으로 시나리오가 잘 작성되도록 하세요.
소프트웨어 개발에서 BDD의 중요성
BDD는 개발직군과 비개발직군 사이의 격차를 연결하면서 소프트웨어 개발에서 중요한 역할을 맡고 있습니다. BDD는 SF 영화속 우주 번역기처럼 모든 사람이 명확히 이해하도록 보장합니다.
BDD는 개발 프로젝트가 사업적인 요구와 사용자의 요구사항 두가지에 모두 집중할 수 있도록 합니다. 각기 다른 역할들 사이에서 통합을 이끌면서, 팀이 풋볼 게임을 해내는 것과 같이 문제를 해결하기 위한 공통된 이해를 쌓아나갑니다.
이러한 통합적 접근법은 빠른 반복, 증가된 피드백, 더 부드러운 가치의 흐름을 가능하게 만듭니다. 여기에 더해서, BDD는 관리 비용과 프로젝트 위험을 줄이면서 코드 품질을 향상시킵니다. 이건 마치 고품질 자재와 단단한 기반으로 오랫동안 안정성을 가질 튼튼한 집을 짓는것과 같습니다.
요약해서, BDD는 일반 언어 예시를 사용해 제품 행동을 지정함으로써 팀이 더 나은 제품을 개발할 수 있도록 해주며, 향상된 통합, 효율성 그리고 마침내 제품의 성공을 이끌어나갑니다.
BDD 테스트가 뭔가요?
BDD 테스트는 사용자의 관점에서 시스템의 행동에 주목하는 소프트웨어 개발 접근법입니다. 이것은 개발자와 QA 엔지니어, 사업 분석가를 포함한 이해관계자들 사이의 통합을 강조해 소프트웨어가 사업 요구사항과 사용자 기대를 모두 달성하게끔 보장합니다.
BDD 테스트에서, 시나리오는 Gherkin과 같은 도메인 특화 언어(DSL)를 사용해 작성되는데, 이는 개발직군과 비개발직군 모두가 이해하기 쉽도록 합니다.
Agile 개발에서의 BDD
클라이언트와 서비스 제공자는 그들이 원하는 것에 대해 대화를 나눕니다.
클라이언트/고객, 개발자, 테스터는 함께 요구사항을 자세히 설명합니다.
그런 다음 요구사항은 구조적인 시나리오에 정의됩니다.
그것은 개발을 돕고 자동화된 테스트와 같은 역할을 하게 됩니다.
이러한 시나리오들은 테스터에게 테스트의 기반으로 사용됩니다.
BDD 라이프사이클
다음은 BDD의 라이프사이클입니다.
1행동 묘사: 이는 제품의 흐름과 특징을 포함하는 주요 비전을 의미합니다.
2요구사항 정의: 공동의 이해를 위해 비즈니스 규칙으로 모델링된 요구사항 정의.
3실패하는 테스트 작성: 실패하는 테스트 개발.
4코드 업데이트 적용: 요구사항에 맞춰 코드 업데이트하기.
5성공하는 테스트 작성: 업데이트된 코드를 실행시켜 테스트 케이스를 통과하기.
하지만 BDD에서 가장 중요한 것은 TDD와 같이 테스트하는 것이 아닙니다. BDD는 비즈니스 목표와 요구사항을 모으는 것을 의미합니다.
SDLC를 더 간단하게 만들기
소프트웨어 개발 라이프 사이클(SDLC)은 모든 소프트웨어 개발을 위한 프레임워크나 사양으로 간주됩니다. BDD는 SDLC를 더 간단하게 만드는데에 큰 기여를 했습니다.
보편적인 영어로 요구사항/시스템 행동을 정의하는 것은 소프트웨어 요구사항 명세서(SRS)를 더 쉽고 명확하게 만들었습니다.
고객, 개발자, 테스터 사이의 큰 화합을 이끌어냅니다.
테스트와 개발 단계에 커다란 긍정적인 영향을 줍니다.
결론
결론적으로, BDD는 통합을 촉진하고, 실행가능한 명세서로 요구사항을 명확히 하고, 사용자 중심적인 결과물에 우선순위를 두어서 소프트웨어 개발을 향상시킵니다. 명확한 대화와 자동화된 테스트를 강조함으로써 BDD는 효율적인 개발 사이클, 높은 코드 품질, 그리고 소프트웨어 개발 라이프사이클에 전반적으로 비즈니스 목표를 통합하는 것을 보장합니다.