프로그래머가 아닌 사람이 실제로 BDD에 쓸 수 있습니까?

상징적 인“Given-When-Then”시나리오 구문을 사용한 행동 주도 개발 구문은 최근 소프트웨어 기능 평가를위한 경계 객체 로 사용하기에 상당히 절실했습니다 .

Gherkin 또는 원하는 기능 정의 스크립트는 비즈니스에서 읽을 수있는 DSL 이며 이미 그와 같은 가치를 제공 한다는 데 동의합니다 .

그러나 나는 프로그래머가 아닌 사람들이 ( Martin Fowler 처럼 ) 쓸 수 있다는 것에 동의 하지 않습니다 .

프로그래머가 아닌 프로그래머가 작성하고 개발자가 계측 한 시나리오에 대한 설명이 있습니까?

실제로 쓰기 불가능에 대한 합의가있는 경우 시나리오 를 시작 하고 계측하는 대신 실제 테스트에서 비즈니스가 읽을 수있는 시나리오를 생성 하는 도구에 문제가 있습니까?

업데이트 : "시나리오 생성기"도구와 관련하여 비즈니스 언어를 마술처럼 추측하지는 않습니다.) 그러나 현재 정규 표현식 매처를 사용하여 하향식 접근법 (추상 차원)에서 테스트를 생성하는 것처럼 사용할 수 있습니다. 상향식 접근 방식으로 시나리오를 작성하는 문자열 빌더.

"아이디어 만 제공"예 :

Given I am on page ${test.currentPage.name}
And I click on element ${test.currentAction.element}
…

나는 그것을 보았다. 끝나지 않았다.

나는이 정확한 이유로 오이가 성가신 (<-lol : D) 추상화라고 생각합니다. 비 기술적 인 사람들이 스스로 작성하기에는 너무 어렵다. 기술자들에게는 너무 장황하다.

비 기술적 인 사람들은 프로그래머처럼 생각하는 법을 배우지 못했습니다. 추상적 지식을 이해하고, 분해하고, 새로 구축하고, 모호함에서 성공적으로 도망 갈 수있는 것이 우리의 특권입니다. 그것이 우리가 지불하는 것입니다.

실제로 쓰기 불가능에 대한 합의가있는 경우 시나리오를 시작하여 계측하는 대신 실제 테스트에서 비즈니스가 읽을 수있는 시나리오를 생성하는 도구에 문제가 있습니까?

도구 자체는이를 생성 할 수 없습니다. 컴퓨터는 비즈니스 영역에 대해 아무것도 모릅니다. 결국 프로그래머는 어쨌든 생성해야 할 것을 이끌어 내야 할 책임이 있으며 심지어는 이러한 시나리오가 최종 사용자에게는 너무 장황하고 암묵적 일 수 있습니다.

고객이 사양 문서를 작성한다는 점에서 어려움의 일부는 고객이 종종 고객이 원하는 것을 실제로 고객이 원하는 것을 설명하는 언어로 번역하는 방법을 모른다는 것입니다. 고객은 시스템에 특정 동작이 존재한다고 말하지만 일반적으로 고객이 자신과 일치하지 않는 방식으로 소프트웨어를보고 사용하고 경험할 때까지 일반적으로 그다지 걱정하지 않습니다. 필요합니다.

고객이 비즈니스 프로세스를 설명 할 때 종종 관련 정보를 많이 남기지 않습니다. 종종이 정보는 고객의 특정 영역 내에서 일반적으로 이해되는 프로세스에 관한 것입니다. 따라서 프로세스는 당연히 받아 들여지고 종종 프로그래머에게 전달되지 않습니다. 다른 경우, 고객은 실제로 시스템 내에서 모든 경계 조건을 처리하는 방법을 알지 못하며 프로그래머에게 지침을 제공하려고합니다. 때로는 고객이 한 가지 방식으로 일하기를 원한다고 생각하지만 나중에 일이 다르게 작동해야한다는 것이 분명 해지면 마음이 바뀌는 단순한 사용 사례 일 수도 있습니다.

"프로그래머를위한 고객 관계 101"은 충분합니다. 문제는 고객이 비즈니스 판독 가능 DSL을 사용하여 사양을 정의하는 방법을 정의하는 데 여전히 가치가 있는지 여부입니다. 저는 지침을 통해 대답은 잠정적 인 '예'라고 생각합니다. 다음으로 떠 올릴 질문은 프로그래머가 더 쉽게 정의 할 수있는 방법으로 프로그래머가 DSL을 만들 수있는 이유는 무엇입니까? 고객에게 시스템 작동 방식을 정의 할 수있는 간단하면서도 풍부한 언어를 제공합니까?

고객에게 시스템 작동 방식을 설명하기위한 언어를 제공하면 다음과 같은 문구가 표시됩니다.

"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".

문이 유형의 고객이 설명되어 그것이에서 고객이 기본적으로 가정 할 수있는 시스템 또는 보는 또 다른 방법을하고자하는 전체적인 모양 제공하는 매우 명확한 방법으로 요구 사항을 설명하는 끝나는 어떤 시스템입니다. 고객이 좀 더 자세히 생각하게하려면 다음과 유사한 여러 문장을 사용하여 기능이 준수해야하는 규칙을 설명하도록 요청할 수 있습니다.

"Given 'some system state', When 'some action occurs', Then expect 'some result'

다시 명확 안내, 약이 시간 방법시스템이 작동해야합니다. 문제는 소프트웨어 개발자가 모든 공란을 채울 필요가없고 고객이 주변에서만 인식 할 수있는 추가 세부 정보를 애타게하지 않아도된다는 것입니다. 고객이 프로그래머에게 친숙한 형식으로 기능과 동작을 설명하기 위해 프로그래머가 '훈련'할 수는 있지만 의미있는 테스트 사례를 생성하거나 구현을 제공 할 수있는 기술이나 지식은 없습니다. 암호. 이것이 OP가 언급 한 Martin Fowler 기사의 요점이라고 생각했습니다. 따라서 소프트웨어 자체는 고객이 쓸 수 없지만 소프트웨어에 대한 설명은 고객이 작성할 수 있으며 IMHO는 반드시 작성해야합니다. 가치있는 것에 대해, 나는 고객이해서는 안된다고 말하는 Fowler의 기사를 읽지 않았습니다.

프로그래머가 비즈니스와 비즈니스 프로세스에 대한 이해 측면에서 우리보다 훨씬 똑똑하다는 사실을 프로그래머가 잊어 버릴 수 있다고 생각합니다. 소프트웨어 시스템을 구축하는 방법을 알려주는 프로그래머가없는 경우 고객은 일반적으로 특정 비즈니스 관리 문제를 해결하기 위해 다른 효율성에 의존합니다. 이것은 단순한 데이터베이스 (Think Access) 나 스프레드 시트, 심지어 손으로 쓴 원장, 프로세스를 관리하기위한 규칙과 절차가 잘 정의되어 있음을 의미합니다. 무엇 많은 고객에게 부족한 것은 결정하기위한 수단 아닙니다 어떻게 작업에 시스템 요구하지만, 그것은해야하지 않고 어떻게 구축 하고, 더 중요한 것은 효율적으로 사람들에게 시스템의 행동 규칙을 설명하는 방법 사람들않습니다 실제로 시스템을 구축 할 수있는 능력을 가지고있다.

실제로 쓰기 불가능에 대한 합의가있는 경우 시나리오를 시작하여 계측하는 대신 실제 테스트에서 비즈니스가 읽을 수있는 시나리오를 생성하는 도구에 문제가 있습니까?

이것이 문제를 잘못된 방향으로보고 있다고 생각합니다. 그 문서가 어떤 식 으로든 사양을 나타 내기 위해 테스트에서 문서를 생성하는 도구에 큰 문제가 있음을 알 수 있습니다. 시나리오를 테스트하려면 시나리오를 이해해야하므로 시나리오를 이미 정의해야 테스트를 정의 할 수 있습니다. BDD 구문으로 시나리오를 설명하는 경우 시나리오를 이미 지정 했으므로 사실 후에 만 ​​시나리오를 계측 할 수 있습니다. 반면에 고객이 프로그래밍 친화적 인 DSL로 시스템을 설명 할 수있는 도구가 있다면,이 도구를 사용하여 테스트 스위트로 사용될 코드 템플릿을 생성 할 수 있다면 그러한 도구에는 큰 가치가 있다고 말할 것입니다. 고객이 프로그래머를 등식에서 제외시키는 것을 보지 못하고 고객의 희망을 취하고 BDD 방식으로 테스트 인코딩 요구 사항을 생성하는 데 필요한 노력을 줄이고 고객의 희망을보다 쉽게 ​​이해할 수 있도록 도와줍니다. 그러나 고객이 고객의 요구를 고객의 요구와 분리 할 수 ​​있도록 숙련 된 소프트웨어 개발자를 대신 할 수는 없습니다.

개발자들이 시나리오를 작성하는 것을 보았습니다. 테스터는 시나리오를 작성하고 심지어 제품 소유자는 시나리오를 작성합니다. 또한 시나리오를 설명하기 위해 대화를 명시 적으로했습니다. -비즈니스 사용이라는 단어를 적었습니다.

내가 얻은 가장 좋은 결과는 사무실에있는 동안 제품 소유자와 대화하고 위키에서 캡처 한 다음 수정하여 추가 할 수 있도록하는 것입니다. 그는 우리 대화에서 놓친 커플을 발견했습니다. 흔들렸다.

내가 본 최악의 시나리오는 개발자가 비즈니스와 대화하지 않고 스스로 작성한 시나리오입니다. "검색 할 때"또는 "오늘 + 3 날짜의 양식을 제출할 때"와 같은 용어를 사용하기 때문에 알 수 있습니다. 일반적으로 그다지 흥미롭지 않은 시나리오, 너무 많은 시나리오, 세부 수준이 너무 낮아서 유지 관리가 불가능합니다. 사업체도 이것들을 읽지 않습니다.

대화 IMO에 집중하는 것이 훨씬 좋습니다. 자동화에 관계없이 몇 팀이 몇 달 동안 품질을 크게 개선하여 지금이 작업을 수행하는 것을 보았습니다. 한 팀은 몇 주 후에 매우 어려운 환경에서 자동화 작업을 수행 할 수있었습니다. 그러나 실제로 팀이 대화를하고 시나리오를 사용하여 다른 시나리오를 작성하는 한 누가 시나리오를 작성하는지는 중요하지 않습니다.

내 경험은 BA (Business Analyst)가 GWT ( Given-When-Then ) 를 작성하는 것이 가장 좋습니다 (SpecFlow를 사용한 경험). BA는 고객 요구 사항을 GWT로 변환 할 수 있으며 비즈니스는이를 읽을 수 있습니다. 고객은 시스템을 이해하지만 기술이 우리가 사용할 수있는 방식으로 요구 사항을 작성한다고 생각하지 않습니다.

이상적으로 BA는 GWT를 작성하고 일부를 수정하고 BA 및 비즈니스가 적용 범위를 확신 할 때까지 반복 검토 / 수정을합니다. 실제로 BA는 내가 정리하고 일할 거친 초안을 줄 것입니다. 비즈니스는 왜 아무도 생각하지 않은 일부 영역을 다루지 않았는지 궁금해하며 으 sh합니다.