테스터를 위한 행위 주도 개발(BDD): BDD에서 당신의 역할

일부 테스터들은 BDD가 자신들의 일자리를 자동화해 버릴까 봐 걱정합니다. 하지만 실제로는 BDD가 테스터들에게 더 큰 역할을 부여할 뿐, 작게 만드는 것이 아닙니다. 테스터는 완성된 결과물을 확인하는 것에서 벗어나, 그것이 구축되기 전에 모양을 갖추도록 하는 역할로 이동합니다.

본 기사에서는 BDD의 각 단계에서 테스터가 어떤 일을 하는지 설명합니다. 전체 프로세스와 도구에 대해서는 behaviour driven development bdd for testers 참고 자료를 확인해 주세요.

발견(Discovery) 단계의 테스터
Three Amigos 세션에서 제품 오너(product owner)가 비즈니스 가치를 가져오고 개발자(developer)가 구현을 담당합니다. 이때 테스터는 '위험(risk)'을 가져옵니다. 당신의 임무는 다른 누구도 묻지 않는 질문들을 던지는 것입니다:

<!--[if !supportLists]-->•       <!--[endif]-->입력이 비어있으면 어떻게 되나요? <!--[if !supportLists]-->•       <!--[endif]-->사용자가 이것을 두 번 수행하면 어떻게 되나요? <!--[if !supportLists]-->•       <!--[endif]-->하위 서비스(downstream service)가 느리거나 다운되면 어떻게 되나요? <!--[if !supportLists]-->•       <!--[endif]-->한계는 무엇이며, 그 한계를 살짝 넘어서면 무슨 일이 발생하나요?

모든 답변은 또 다른 예시가 되고, 종종 또 다른 시나리오가 됩니다.

형성(Formulation) 단계의 테스터

테스터들은 종종 예시들을 Gherkin으로 변환하는 데 가장 적합한 사람들입니다. 당신은 이미 전제 조건(preconditions), 동작(actions), 그리고 예상 결과(expected results)에 대해 생각하고 있으며, 이는 Given, When, Then에 직접적으로 매핑됩니다.

시나리오: 일일 한도에서 정확히 인출하는 것이 성공함

  Given 일일 인출 한도는 1000입니다

  And 고객이 오늘 0을 인출했습니다

  When 고객이 1000을 인출합니다

  Then 인출은 성공해야 합니다

이러한 경계 시나리오(Boundary scenarios)는 바로 테스터가 가치를 더하는 지점입니다.

자동화(Automation) 단계의 테스터

팀에 따라 테스터가 직접 스텝 정의(step definitions)를 작성하거나 개발자와 페어 프로그래밍을 할 수 있습니다. 어느 쪽이든, 테스터는 중복된 스텝, 불안정한 시나리오(flaky scenarios), 느린 테스트 등을 발견하여 테스트 스위트가 건강하게 유지되도록 합니다.

시나리오 이상의 테스트

BDD 시나리오는 합의된 동작을 다룹니다. 이는 탐색적 테스트(exploratory testing), 성능 테스트(performance testing) 또는 보안 테스트(security testing)를 대체하지 않습니다. 테스터가 여전히 이 영역들을 담당하며, 종종 다음 발견 세션에 활용될 새로운 예시들을 찾아냅니다.

BDD에서 테스터에게 도움이 되는 기술

<!--[if !supportLists]-->•       <!--[endif]-->**도메인 지식(Domain knowledge):** 테스트하는 비즈니스 규칙을 이해하는 능력. <!--[if !supportLists]-->•       <!--[endif]-->**명확한 작문(Clear writing):** 시나리오는 비기술적인 사람들에 의해 읽히기 때문입니다. <!--[if !supportLists]-->•       <!--[endif]-->**기본 코딩(Basic coding):** 스텝 정의를 읽고 작성하기에 충분한 지식. <!--[if !supportLists]-->•       <!--[endif]-->**촉진자 역할(Facilitation):** 발견 세션이 집중되고 짧게 유지되도록 돕는 능력.

자주 묻는 질문

BDD에서 테스터가 코딩을 해야 하나요?

기본적인 코딩 지식은 도움이 되며, 특히 스텝 정의의 경우 그렇지만, BDD에서 가장 가치 있는 테스터 기술은 질문하고 명확하게 작성하는 능력입니다.

BDD가 수동 테스트를 대체하나요?

아닙니다. 아무도 예측하지 못한 문제를 찾는 데 있어 탐색적 테스트는 여전히 필수적입니다.

마지막 생각

BDD에서 테스터는 상류(upstream)로 이동하여 코드가 존재하기 전에 품질에 영향을 미칩니다. 수동으로 회귀 테스트(regression tests)를 작성하는 시간을 줄이려면, 실제 API 트래픽으로부터 이를 생성하세요. Keploy API 테스트 알아보기.